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[57] ABSTRACT 

A Telecom Access Billing System provides the capability for 
a communication carrier service provider to substantially 
automate the payment to other communication carrier ser- 
vice providers for the use of their services and equipment. 
Billed charges are received in a variety of forms from the 
communication carrier service providers which are provid- 
ing the services. A processor uploads the information, 
checks its integrity, and converts it to a format in which it 
can be further processed. Once the information has been 
uploaded and converted, a validation process is performed in 
which the individual ite ms of the bill are checked as to 
whether the rate information charged by the communication 
carrier service providers matches the rates which have been 
either negotiated or established by a third party. Any dis- 
crepancies noted in this comparison process are included in 
a dispute report which is associated with the invoice on 
which the billed charges appear. The user of the system may 
then review the invoices in conjunction with any discrep- 
ancy amounts which have been noted. An automated pay- 
ment module then provides for the electronic transfer of 
funds to the communication carrier service provider for 
approved invoices. 

28 Claims, 18 Drawing Sheets 
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TELECOMMUNICATIONS ACCESS COST of different types of storage media in accordance with 

MANAGEMENT SYSTEM preprogrammed instructions and/or in accordance with 

inputs from at least one graphical user interface (GUI). In 

FIELD OF THE INVENTION conjunction with accessing the billed charges, the billed 

The present invention relates generally to billing systems, 5 charges may be initially uploaded from the storage media to 

and more particularly, to a system for verifying charges an upload module in the processor. The option also exists for 

between communication carrier service providers. manually loading the billed charges into the upload module 

The system is particularly apt for use in automatically &™Z h GUL ° Qce information has been uploaded, 

verifying, paying and/or analyzing billed charges between a vanet y of anal y ses ma ? be Permed, 

telecommunication carriers. 10 In one arrangement, an integrity check is performed on 

the billed charges to confirm that no corrupted data has been 

BACKGROUND OF THE INVENTION transmitted. A duplicate billing check is also performed to be 

The provision of communication services to businesses smc that ±Q biUed cnar g e s currently being received are not 

and individuals often entails the transmission of voice, duplicates of charges previously transmitted. After these 

image and other data via the use of communication devices 15 checks have been Performed and the incoming billed 

maintained by different communication carrier service pro- charges have been parsed, a conversion process may be 

viders. While the provision of such communication services performed in order to convert the bill data into a second 

may be adapted to appear "seamless" to users, e.g., via file format which can be processed internally by the 

consolidated billing by a single carrier to its customer, the system (e.g., via relational database management 

underlying cross-carrier services are in fact billed between 20 techniques). A report may also be generated documenting 

the cooperating service providers on a periodic basis. me upload and conversion of the billing information. When 

. By way of primary example, multiple telecommunication ^ data upload/conversion is complete both the report and 

carriers may be utilized to complete a given long distant the bllled char 8 es are loaded mto a Paction database, 

call between two remote locations. The call may be initiated 0nce m tne database, a validation process may be per- 

by a caller via interface with the caller's local telephony formed to check the actual charged rates against reference 

carrier service provider, transferred for interstate transmis- charge rates. The reference charge rates may be negotiated 

sion to a long distance service provider, and further trans- between the parties or previously established by third parties 

ferred to a local telephony service provider for the called ( e -S-> regulatory agencies). The billing information is 

party. In such an arrangement, while the caller's local 3Q retrieved from the production database and comparisons are 

telephony carrier service provider will bill the caller for made between what the second service provider charged 

charges associated with the call, the long distance service versus what the first service provider has identified as the 

provider and called party local telephony carrier may bill the appropriate reference rate. Also, this comparison is made for 

caller's local telephony service provider. The amount the tariffs or other third-party established rates. At this point, 

charged between various communication carrier service 35 an y discrepancies between the actual charged rate and the 

providers may be as per regulated rates and/or agreed upon reference rate are noted. 

contract rates, and may further depend upon a variety of The validation process may be performed by an automatic 
other considerations (e.g., volume of communications validation module incorporated in the graphical user inter- 
between carriers, time-of-day of communications between face. The process may be performed automatically after the 
carriers, degree of special access between carriers, band- 4Q billed charges have been uploaded to the database. The 
width allocated for communications, etc.). automatic validation module includes all the criteria neces- 
As will be appreciated, given the ever-increasing volume sarv i n ord er to validate the billed charges. The automatic 
of communications involving multiple carriers, the handling validation module may be configured such that the first 
of cross-carrier billings can be quite complex. service provider may program in selected requirements for 
Concomitantly, the validation, payment, and analysis of 45 performing the validation process. 

such cross billings can be burdensome, particularly in view The discrepancy information which is generated in the 

of highly labor-intensive techniques currently employed to validation process may then be used in a dispute-tracking 

provide such functionality. process. For example, for billed charges in which a discrep- 

^. r „ ; , ancy is noted, a dispute report may be generated which 

SUMMARY OF THE INVENTION ^ mcludes the ^pancy amount. A dispute tracking module 

Described herein is a system and method for improved may be included in the GUI which provides the system user 

handling of billed charges between communication carrier with a number of displays which may be used to enter 

service providers. The system contemplates an arrangement comments and other information relating to the dispute 

in which a first communication carrier service provider is report. Once the dispute report is generated, the system user 

billed for services by a second communication carrier ser- 55 is provided the functionality to associate the billed charges 

vice provider, the billed charges most typically received in with the dispute report. The system user may also update, 

a first digital file format. Of importance, the billed charges amend or resolve any dispute reports which have been 

include a plurality of entries which have a corresponding previously generated for other billed charges, 

billed charge rate components. In one aspect of the Once a dispute report is generated for the billed charges, 

invention, when the first carrier receives the billed charges, 6 o a system user may be provided the opportunity to either 

corresponding reference charge rates are automatically approve or disapprove an invoice, which the billed charges 

retrieved from a database maintained or otherwise readily are part of, through a bill review and approval process. A bill 

accessed by the first carrier. The billed charge rates and the review and approval module may be incorporated into the 

reference charge rates are then automatically compared in GUI which provides the system user the ability to access and 

order to determine if a discrepancy exists therebetween. 65 display invoices along with dispute reports. In one aspect of 

The system described herein may include a processor the invention the invoices and dispute reports are displayed 

which may access data (e.g., billed charges) from a plurality to the system user in a hierarchal structure. By using the 
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computer mouse, the user may select subcategories of the FIG. 17 discloses a screen display which provides for 

invoices and dispute reports to reveal additional information searches of information currently displayed in the main 

about a particular matter. Invoices and disputes may be window. 

associated through the dragging and dropping of a particular nG. 18 discloses a flow chart which describes the opera- 
invoice on top of a particular portion of the dispute report. 5 tion of the output module. 

Once all the billing and dispute information has been 

reviewed, the system user may either approve payment for DETAILED DESCRIPTION 

the invoice or may reject the invoice and have it returned to Disclosed in FIG. 1 is a system diagram for the cost 

the validation process. If the invoice is disapproved, the teacking system which shows m particular the and 

system user can insert notes in the invoice as to why it was M external ^^ons for processor 8 and graphical user 

rejected. If the system user approves the invoice in the bill mter face 14. The processor 8 may be implemented as a 

review and approval module, that invoice is then forwarded UNIX or m server whfch may establish OD BC TCP/IP 

for automatic payment. The user may approve the billing conncc tions over a data network 15 with remotely located 

information even if a dispute report has been associated and processing devices. The data network 15 may be the 

can order that a reduced amount be paid which reflects the is MtsaKtf an mtranet> or type of node based computer 

discrepancy noted. system. Within the processor are upload module 12, pro- 

Once a invoice has been approved for payment, an duction database 16, as well as the output module 24. These 

autopayment process can be triggered to electronically pay elements will be discussed in greater detail below, 

the invoice. An automatic payment module may be incor- ^ shown u pre. 1 is graphical user interface (GUI) 14. 

porated into the processor. As part of the autopayment *> j n 0De embodiment of the invention the GUI is a personal or 

process, a precautionary procedure may be used which olher stand ^ mer which te in , he m Qr 

requires a certain level of approval (e g, by upper man- wkliows 95 eavir0Q[n ent. The GUI includes the capability 

agement personnel) to pay the invoice if the charges exceeds (o dj k information> allows the system ^ to initiate 

a predetermined amount. In the case where a dispute report commands, and provide for the manual input of data, 

has been attached to the invoice the short pay amount may Communication between the GUI 14 and the processor 8 is 

be electronically transmitted to the vendor, and the dispute estabUshed over a OD BC TCP/IP connection established 

report otherwise provided to the vendor for review. Once a ovef data netwofk 15 ^ ffl ^ ^ plG x shows 

dispute report is resolved, tee status of this report may be ^ ^ of , ^ GUI for lanation onl ^ 

changed in the dispute-tracking module. ^ CQSt tracking system described herein may incorporate mul . 

Numerous additional aspects and advantages of the tiple GUI's. The GUI 14 further includes validation module 

present invention will become apparent to those skilled in 18> dispute tracking module 20, and bill review and approval 

tne art - module 22. These modules will be described io greater detail 

DESCRIPTION OF THE DRAWINGS below - 

FIG. 1 discloses a system diagram for a cost tracking 35 ,. I* 6 c ° st s £!f m ' as described herein ' snbst f 

system which shows internal and external connections to a ^ auton f ^ tbe bl " Processing by a customer for 

, , • « _r charges made by a vendor for use of its equipment or 

cost tracking server and graphical user mterface. r ^ ... Aj .... • 

„ , ° a , services. The embodiments described herein refer to the 

FIG 2 disc oses a flow chart which describes the opera- bming procedures for telephony services, however one 

tion of the upload module. 4o &m&d {n ^ ^ n ^ ^ ^ system described 

FIG. 3 discloses a flow chart which describes the opera- herein may have applications which extend beyond this 

tion of the automatic validation module . particular area of business and technology. As is well known, 

FIG. 4 discloses a screen display for the main window. there are many different communication service providers 

FIG. 5 discloses a screen display for the new dispute which provide telephony services for individuals and busi- 

window. 45 nesses. These providers may not own all the communication 

FIG. 6 discloses a screen display for locating dispute lines which are used in order to provide their services. For 

reports. example, a long-distance phone carrier in most cases does 

FIG. 7 discloses a screen display for the main window not own tne local P none lines but, instead, must obtain 

which includes located dispute reports and invoices. access to these lines through a vendor. Agreements are 

FIG. 8 discloses a screen display for the definition of a 50 established between the long-distance carriers and the local 

dispute report phone companies for use of particular lines. Periodically, the 

FIG. 9 discloses a flow chart which describes the opera- ™ ndor *f ^ nd t«*aistomer a bill which includes charges 

tion of the dispute tracking module. for use of lts 1 Imes - ^ desenbed herein substantially 

™^ i i-i r 1 * • ■ automates the processing and payment process for these 

FIG. 10 discloses a screen display for locating invoices. .n . . 

CTr , t1 . / . . , * . . 55 billed charges. 

FIG. 11 discloses a screen display which lists invoice „ r . . A ™^ t i_ c jj-*- i i 

r J Referring again to FIG, 1, a number or additional ele- 

+~ i « . i . . , .. . ments are shown to have external connections with the 

. FIG ; 12 ^ a fl0 ^ Chart Wh , ich ^scribes the opera- ssor 8 0qc coanec ti on is made to external data source 

tion of the bill review and approval module. 1Q Extemal da(a SQUrce 1Q represeDts me submission of lhe 

FIG. 13 discloses the functionality included in the view 60 biUed chargcs by the vcndor to the cust0 mer. The vendors 

pull down of the mam window. may submit the billed charges through a variety of means. 

FIG. 14 discloses the functionality included in the tools Some examples are CD-Rom's, diskettes, 9-track tape, car- 
pull down of the main window. tr i d g e tape, and electronic file transfer. The information on 

FIG. 15 discloses a screen display for providing vendor these different media may be in a number of different 

information. 65 formats. Some examples of possible data formats are CABS, 

FIG. 16 discloses a screen display for providing account CENTREX, AEBS, CRIS, as well as any custom formatted 

information. carrier electronic bill data. 
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Two other connections from the processor are made to module 12. The upload module 12 provides the capability to 

autopayment interface 13 and the invoice and dispute report upload data generated by a vendor's billing system into the 

output 17. The autopayment interface 13 facilitates the production database. The uploading of data may be incor- 

automatic payment of approved charges through electronic porated as an automatic function for processor 14. The 

or other means. The invoice and dispute report output 5 system user may program the server to make inquiries of the 

provides copies of invoices and dispute reports to the external data sources as to whether there is data available to 

vendor. One implementation for the invoice and dispute upload. This process may also be initiated manually by the 

report output 17 is a printer which provides these items in svstem user throu S h a c °mmand submitted through the GUI. 

hard copy format. These items may also be provided in an Dunn S the u P load of ±c vendor's billed charges, the upload 

electronic document format. 10 modu l e performs data integrity and format integrity error 

A j , o ■ 1 j checking on the uploaded information and prevents cor- 

As was mentioned above, the processor 8 includes a ♦ j j . # u • i^^-**u * ij 

number of internal elements. Upload module 12 performs m P' ed da a from b«ig "ploaded mto the system. The upload 

the function of uploading the billed charges from external ™ dulea ° queries the production database to ensure that 

data source 10. In addition, this module performs a variety du f hc . ate are n °' loaded f° * e ^stem Fmally the 

of data analysis functions on the uploaded information, and 15 upload module records information pertinent to the load 

converts the information from whafever format it is received Um f' d ™' 10n > ™**™ot records) and associates that da a 

to a relational database format. Once this conversion is J vendJ^ fbiUs' 8 " " $ 

complete, the billed charges are stored in production data- _ . ' . „ 

base 16. Database 16 is a relational database which contains ™ e fl ° w char \ m nG - \ de«cnbes in detail the steps 

multiple tables which are searchable by the system user. This *> performed in the data upload process. At the beginning of 

database may be implemented in a number of relational ^ P«J°f«» a query is made as to whether the uploading of 

formats which may include Oracle, Sybase, or any other 'he billed charges will be an automatic or a manual process, 

relational database software. Also stored in the production ? the P rocess 18 mamlal > user of the s y s,em P uUs U P tne 

database is variety of reference information which may be deslred . scree ° dls P la y ! hrou g h the GUI . and enters the 

used by other components of the system to perform analysis 25 appropriate information for the vendor. This information is 

on the billed charges already in the relational database format so it is stored 

_ « c ' • . , , , , ,, ml . directly in the production database. If the upload of infor- 

The processor 8 further includes output module 24. This t . • j- .i. i . ■ 

. , r , . matron is from an electronic media or other electronic 

module provides for the processing of billed charges once g ^ ]oad o£ ^ mformation from ^ extemal data 

they have been approved for payment This processing may SQUrce M fa ^ Ml£I the mfolmation b up i oaded to 

include the initiation of autopayment for the charges as well ^ load ; ^ & ^ h made as (o 

tTantL°tion Utting ^ documentatlon about the whether the billed charges are in a recognizable format. As 

was described above, the vendors may store their billed 
GUI 14 also includes a number of internal processing charges in a particular electronic format which the processor, 
modules. The automatic validation module 18 retrieves the 35 md more specifically, the upload module needs to translate 
converted billed charges from the production database and m order to store the informatioD in the production database, 
performs a variety of processes on the billed charges which If the information format is not recognizable, the process is 
mcludes a check on the validity of the vendor making the aborted ^ an error log for ihis step ^ prodllced< If the 
charge, the detection of any discrepancies in the billed information is in a recognizable format, an integrity check is 
charges received when compared against reference informa- 4Q then performed. This check is performed to be sure that no 
tion in the production database, and the calculation of any corrupt data ^ loaded onto tne pro duction database. If 
discrepancy amounts. corrupted data is detected, the process fails and the down- 
Any discrepancies detected in the automatic validation load is aborted. If the data passes through the integrity 
module are further processed in dispute-tracking module 20. check, the upload module performs a scan of the billed 
The dispute -tracking module 20 creates a dispute report 45 charges which have already been downloaded onto the 
which describes the discrepancy and discrepancy amount. production database to be sure that none of the entries are 
This dispute report is then associated or otherwise connected duplicates of billed charges already in the system. If any 
with the billed charges. The bill review and approval module duplicates are detected, the process fails and the upload is 
20 receives the billed charges, and within this module, the aborted. 

user of the system may access the billed charges and review 50 rf me data passes through the integrity and duplicate entry 

anyonhe_charge^^ by the vendor. The user can also cne ck a the information stream is then parsed into individual f 

access any dispute reports which have been generated at the billing entries. Each data format has its own header infor- 1 

dispute-tracking module 20. At the bill review and approval mation which me upload modu i e translates and uses to 

module 22, the user may either approve payment of the properly parse the information. Once this step is complete, 

billed charges or reject the bill and return it to the database 5S me upload modu i c converts the billed charges from their 

for further review in automatic validation module 18. uploaded format to a relational database format for storage 

In one embodiment of the invention, modules 18, 20, and onto the production database. A number of relational data- 
22 are part of a cost tracking software package which is base formats can be used for this particular process. These 
downloaded on to the GUI. This software may operate in the formats may include Oracle, Sybase, or any other known 
Windows 95 or NT environment. Through the connections 60 relational database software. After the conversion process is 
established over the data network from the GUI to the complete, a report is generated on the uploaded and con- 
processor, these modules may be used by the system user to verted billed charges and the information is then stored in 
access, perform searches, and retrieve data from the pro- the production database. The upload logs are populated with 
duction database 16. The production database includes the data which includes the upload times, durations, and number 
necessary logic to facilitate this access. 65 of records read by type. 

In operation, billed charges from a vendor are uploaded Once the billed charges have been properly converted and 

from the external data source and received at the upload stored in the production database, the analysis of the billed 



01/09/2003, EAST Version: 1.03.0002 



6,144,726 

7 8 

charges may begin. A first portion of this analysis is done in circuit. If this is a circuit charge, another query is made as 

automatic validation module (AVM) 18. The basic function to whether the circuit is valid. According to agreements 

of the automatic validation module is to perform compari- made between the parties, access is provided to particular 

sons between the billed charges and reference information circuits according to certain terms. After certain amounts of 

previously stored in the production database. This reference 5 time, circuits may be deactivated or access is denied to that 

rate information includes such things as rates agreed to by circuit. The circuit validity check determines whether the 

the parties for use of the circuits as well as any tariffs customer is being billed for accessing a circuit which had 

established by third parties. The automatic validation mod- been deactivated or was not accessible by the customer, 

ule provides the user with the ability to query the database If it is determined that the circuit is invalid, the billed 

for detailed billed items using multi-dimensional criteria 10 charge is flagged so that a discrepancy report can be gen- 

across billing account numbers (BANs) and bill dates. This erated. If the circuit charge is valid, a check is then made as 

criteria may include all charges for a particular vendor over to whether there had been a contracted rate between the 

a particular time period or it may be narrowed down to a parties. The parties will enter into agreements charging 

particular charge. The AVM has access to contract data, any particular amounts for the use of particular circuits. If the 

circuit mileage and rate data to support mileage rate calcu- 15 rate charged is not valid according to the reference charge 

lations where applicable, circuit and inventory data to sup- rates stored in the production database, the billed charge is 

port charge validation by circuit, and PIU (percents interlate flagged, and a discrepancy amount is calculated. If the rate 

utilization ) data to support PIU discounting. This module is valid and all other information check outs in the bill, the 

also allows bulk dispute item selection and flagging and billed charge is sent to the bill review and approval process, 

allows the customer to maintain a comprehensive catalogue 2Q If there had been no contracted usage rate between the 

of reason codes that are associated to disputable bill items. parties, a final query is made as to whether there is an 

Additional functionality may include the re-analysis of applicable tariff for the charge. Governmental entities or 

billed charges which have gone through the system once and other third parties may impose a tariff or other charges on the 

have been disapproved for payment. use of particular services within their jurisdiction. If there is 

The automatic validation module described herein 2 s a tarm ° associated with the billed charges, this tariff rate is 
includes the functionality to accept custom programming. compared against a reference rate stored in the database. If 
The module is programmable by the system user to perform the tariff rate is not correct, it is flagged, a discrepancy is 
the validation process according to unique requirements calculated, and this discrepancy information is transmitted 
established by a particular client. This programming can be to the dispute tracking module. If the tariff charges agree, the 
done through the GUI. For example, any of the criteria 30 billing information is transmitted to the production database 
described above, such as contracted rates and tariffs, that are for access through the review and approval module. Any 
used in the validation the billed charges may be changed discrepancy information which had been calculated in the 
based on the requirements of the party performing the automatic validation module is transmitted to the production 
analysis. The AVM is designed such that the user may database so that it may be retrieved through tie dispute 
interact with and maintain client specific requirements 35 tracking module 20. The dispute tracking module 20 pro- 
through the GUI. vides the capability to create, package, and track disputes. It 

The AVM also has capability to produce and store sum- allows the system user to query the database for disputable 

mary reports for the billed charges processed by the AVM. items across a number criteria, which includes BAN's and 

These reports may include information relating to the num- bill dates, and then include those various details in a dispute 

ber of validation errors found by reason code and in total. 40 report. That dispute report then becomes an entity within the 

The summary reports of the validation processing may also system, which can be tracked, reviewed, and finally closed 

provide information relating to cycle breakdown of billing after resolution with the vendor with whom the dispute is 

errors found in each invoice processed, breakdown of error being pursued. The dispute report is linked to the billed 

codes by type, dollar amounts, number of errors types found, charges from which it was created, and is viewable from 

etc. 45 other modules in the processor. 

Disclosed in FIG. 3 is a flowchart which describes an In order to create a dispute report from discrepancy 

example process which may be used to analyze billed information, the system user, from the GUI, first accesses the 

charges for a communications service provider. Upon a main window screen for the cost-track system. The main 

command by the user or through an automated process, the window is the screen display which provides the starting 

automatic validation module accesses the production data- 50 point from which all screen displays discussed herein are 

base and uploads the billed charges which have been iden- accessed. The main window is also the screen display which 

tified through user established criteria. This criteria may is returned to when the other screen displays are closed out. 

include the particular vendor, a particular billing entry, a This screen is shown in FIG. 5. In this main window, there 

particular circuit, as well as the re-analysis of a bill which are a number of pull-down menus which the system user can 

had been disapproved for payment. The production database 55 access to perform a variety of functions. In the case where 

provides for searches using a variety of different search the system user wishes to create a new dispute report, the 

terms. After the billed charges have been uploaded, a query user would first select the file on toolbar 30, and then select 

is made as to whether the vendor is valid. Included in the new 32, and then dispute 34 from the pull down menus, 

production database is a list of vendors which have provided Once these selections have been made, the screen display 

services to the customers. If the vendor is not on the known 60 disclosed in FIG. 5 is provided for the system user, 

or approved vendor list, the bill is sent directly to the review The screen display shown in FIG. 5 provides the system 

and approval module. If the vendor is identified, the module user a mechanism to enter information about the dispute 

performs a check on the billing statement to confirm that, report to be created. This information to be input may 

based on the vendor provided usage rates, the charges shown include such things as Notice #, Vendor #, BAN # and any 

are correct. If these charges are not correct, an error state- 65 other relevant information. Once the creation of the dispute 

ment is attached to the billed charges. A query is then made report is complete, it appears on the main window. FIG. 7 

as to whether the billed charge is related to use of a particular discloses a screen display of the main window which 
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includes a series of dispute reports which have been created. 
All the dispute reports shown in the left hand column are 
arranged in a hierarchial structure. Beneath each dispute are 
a number of subcategories containing information about the 
dispute. By using the mouse and left clicking on any of these 
reports or subcategories, additional subtopics are displayed. 
Right clicking on any of these icons in the hierarchal 
structure will initiate the display of a screen which contains 
specific information about the item in question. For 
example, shown in FIG. 8 is a dispute definition screen for 
a particular dispute. Included in the detailed information are 
items such the node selected from the dispute report hier- 
archy 36, the disputed amount 38, a reason code 40, and any 
comments included in the dispute report 42. When the user 
is finished viewing the dispute report information, the okay 
button may be selected and the system user is returned to the 
main window. The informational screen displays for a 
particular dispute, may also be used to amend information 
within the dispute report. 

Returning again to the main window screen display 
disclosed in FIG. 4, a system user may also access dispute 
reports which have already been created in order either 
amend or delete these reports. Under the file block 30, the 
system user would choose open and then dispute. Once this 
choice is made, the screen display disclosed in FIG. 6 would 
appear would and provide the user with various subject areas 
in which to search for disputes. The system user may choose 
the pull down menu 46 which discloses a number of subject 
headings in which to search. These headings may include 
dispute report number, total disputed amount, particular 
vendor, BAN, as well as a variety of other topical headings. 
The scope of the search may be limited by entering infor- 
mation in block 48, and once the user presses okay, a list of 
dispute reports which match the search criteria are displayed 
in the main window screen display. 

FIG. 9 describes in detail the steps performed by the 
dispute tracking module. As was described above, the dis- 
pute tracking module is provided access to discrepancy 
information generated by the automatic validation module. 
Upon receipt of this information, the system user may then 
generate a dispute report. If the user wants toj;reateadispute 
report for a discrejpanc ^detected in "the billed charges, the 
module retrieves this discrepancy information. The discrep- 
ancy information is displayed to the system user and a screen 
display is provided to enter a dispute description. After this 
dispute description is entered, the module associates all of 
the appropriate billing information, vendor, BAN, dates, etc. 
in the dispute report. This information provides the connec- 
tion between the billed charges and any discrepancies which 
have been detected. This dispute report then can be stored in 
the production database. 

As described above, the dispute resolution module also 
provides the opportunity to modify, review, or delete a 
dispute report. If the user wants to modify or review a 
dispute report, the user enters the information through the 
GUI and the dispute module will retrieve the particular 
dispute report from the production database. This retrieval of 
a dispute report can be done in conjunction with functions 
being performed in other modules in the cost tracking 
processor 8, for example the bill review and approval 
module 22. Once the dispute report has been retrieved, it is 
displayed in its hierarchal structure through the GUI. The 
system user is then provided the option to make any changes 
or amendments to the dispute report. If the user does not 
make any changes, the dispute report is left unchanged. If a 
change is made to the dispute report, the user enters this 
change through the GUI and it is incorporated into the 
dispute report. 
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The user of the system also has the option of closing a 
dispute report once the discrepancies noted in the billed 
charges have been reconciled. To begin, the user enters the 
identifying information for the dispute report through the 

5 search function incorporated in the GUI, and the appropriate 
dispute report is retrieved. The dispute report is displayed 
and the user of the system, through a particular dialog box 
on a screen display, may indicate that the dispute has been 
resolved and this dispute report should be closed. A record 

10 of this dispute is kept in the production database and this 
record includes all information relating to the creation and 
closing of the dispute. 

After the billed charges have been processed in the 
automatic validation module and any discrepancies noted in 

15 the dispute module, the billed charges are combined in 
invoices for the different vendors, and the system user then 
approves or disapproves the invoices in the bill review and 
approval module 22. The bill review and approval module 
supports the process of reviewing invoices and dispute 

20 reports and approving invoice/dispute packages for payment 
or formal dispute. Using this module, users may view 
summary information on the charges (including short pay/, 
disputed amounts), link to detailed information on bill items 
(linked to validation/bill research module), or link to dispute 

25 detail (dispute-tracking detail). Finally, the bill review and 
approval module provides the functionality to associate 
summary invoice amounts with general ledger codes for 
accounting and financial tracking. 

Before a invoice can approved, it must first be manually 

30 reviewed by the system user. The dispute reports associated 
with that invoice should also be reviewed. The invoices may 
be displayed to the viewer in a manner similar to how the 
dispute reports were displayed. Referring again to the main 
window shown in FIG. 4, the system user would choose the 

35 file block on tool bar 30, then choose the open block 32, and 
then choose invoice from pull down menu 34. At this point, 
a screen display will be provided which allows the user to 
search for invoices. An example screen display is shown in 
FIG. 10. By choosing the pull down menu 50 in this screen 

40 display, the system user can choose from a variety of search 
areas. These areas may include invoice numbers, vendors, 
bill amounts, etc. In the example where the total bill amount 
is the search criteria used, this search can be further limited 
by entering a maximum value in block 52. Once the search 

45 has been completed, all the invoices which meet the search 
criteria are displayed on the main window. An example of a 
retrieved list of invoices is shown in FIG. 7. As with the 
dispute files, all information about a particular invoice are 
presented in a hierarchial structure. For example, under a 

50 invoice CABS 28: Feb. 19, 1998, there are a number of topic 
headings which include the total amount due, beneath that 
the total charges and the total balance due, and further 
beneath that are the total balance due, the adjustment 
applied, payment applied, as well as the total last bill 

55 amount. By right clicking with the mouse on any of these 
items for information about that portion of the invoice may 
be viewed. For example, by right clicking on the invoice 
description portion, a screen display like the one in FIG. 11 
is provided. This screen display provides the system user 

60 with the current status of the invoice, including any disputed 
amounts. 

One piece of information which may be necessary in 
order to approve payment of a particular invoice may be 
whether a particular dispute report is associated with that 
65 invoice. Invoices and dispute reports are associated through 
a manual function performed by the system user. The first 
step in this process is to display both the dispute reports and 
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the invoices on the main window. The screen display pro- 
vided in FIG. 7 shows both the disputes and invoices on the 
main window. In order to associate a particular dispute with 
an invoice, the user takes advantage of the drag and drop 
functionality included in the system. For example, if the 5 
system user wishes to associate a dispute 1 with the invoice 
CABS 28: Feb. 19, 1998, the system user would grab the 
invoice icon with a left click of the mouse, drag it across the 
screen and drop it on top of the dispute report icon. From 
that point on the invoice detailed information will contain a ^ 
reference to the dispute report to which it has been associ- 
ated. Conversely, the dispute report will now note discrep- 
ancy amounts included in the invoice. The drop and drag 
functionality described above provides the flexibility to 
associate multiple invoices with a particular dispute report. 

The detailed operation of the bill review and approval 15 
module is disclosed in FIG. 12. After a user has accessed the 
bill review and approval module, the system user requests 
that particular billed charge be retrieved from the database. 
After the request is input through the screen display, the 
billed charges are retrieved from the production database 20 
and displayed for the user. As was discussed above, all 
relevant information including itemized charges and dispute 
reports are displayed for the system user to review. During 
the review process the user may request to view the dispute 
report associated with the invoice. Once this information has 2 5 
been retrieved, it is displayed for the user to review. Once 
the system user has all the information necessary in order to 
either approve or disapprove a bill, a query is made as to 
whether a change of bill status is desired. The system user 
may choose to leave the bill information unchanged and 3Q 
return to it at a later point. 

If the system user does wish to change the status of the 
bill, the user may approve or disapprove the bill for pay- 
ment. The system user may mark the bill as approved in at . 
least two scenarios. If there is no discrepancy report asso- 
' ciated with this charge, the bill may be marked to be paid. 35 

If there is a discrepancy noted and an associated dispute 
\ report for this bill, the system user can mark the bill to be 
short paid and a discrepancy report sent to the vendor. Once 
these designations have beea made, the bill is forwarded to 
the output module. If the system user decides to disapprove 4 ° 
the bill, it is marked as rejected. A dialog box is provided in 
the invoice for the system user to enter reasons for the 
rejection. Reasons for rejection may include disagreement 
with the dispute report and, in particular, disagreement with 
the noted contract or tariff rates. Once the bill has been 45 
disapproved, it is transmitted back to the automatic valida- 
tion module for further review. Once in the automatic 
validation module, a system user may assist the automated 
functions in that module to correct any errors noted in the 
dispute report. 50 

A variety of other functionality is provided to the system 
user through the main window. Through the view pull down 
menus on tool bar 30, the system user has the option to 
expand a the hierarchial listing for one or all dispute reports 
and invoices. The option is also provided for collapsing the 55 
hierarchial structure for these same items. These options are 
shown in the screen display disclosed in FIG. 13. 

Under the tools pull down menu as shown in FIG. 14, the 
system user is given the option of reviewing or amending 
information relating to a particular vendor or a particular 60 
account. In the situation where the system user chooses the 
vendor maintenance option, a screen display, as disclosed in 
FIG. 15, appears. In the find portion of the screen display, 
the user may enter a particular vendor, a vendor name, and 
the desired information for that vendor will appear below. 65 
Also with this screen, the system user may enter new vendor 
information 
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If system user chooses the GL account maintenance 
option in the tool pull down menu, the screen display shown 
in FIG. 16 will be displayed. Through this screen display, the 
user can search for a particular account using account 
number or other identifying information. This information is 
then displayed for the system user. Also through this screen 
display, the system user may enter new account information. 

Additional functionality provided in the main window is 
the ability to search disputes and invoices which are cur- 
rently being displayed. Under the edit pull down on tool bar 
30, the find function may be selected and the screen display 
shown in FIG. 17 is provided for the system user. Within this 
screen display, the user can choose a particular subject area 
to search within and then in the right hand column enter 
limitations to that search The search is only performed on 
items currently being displayed in the main window. 

If the invoice has been approved in the review and 
approval module, it is then transmitted to output module 24. 
The output module provides a generalized output format for 
both the accounts payable/bill disbursement file output (to 
electronically pay the billed charge via the client's automatic 
payment system) and also for the dispute report which is sent 
back to the vendor with whom a dispute is being pursued. * 
These outputs may be either driven by a command entered 
through the GUI or outputs with an automatic scheduling 
system. 

The flow chart disclosed in FIG. 18 describes in detail the 
processes performed by the output module 24. After 
approval in the bill review and approval module, the billed 
charge is received by the output module. A first query is 
made as to whether the billed charge to be paid has a dispute 
report associated with it. If there is a dispute report 
associated, it is retrieved and output through a printer or 
other output device in hard copy form. Once in hard copy 
form the dispute report can be sent to the vendor. After the 
dispute report has been printed out, a query is made as to 
whether the amount to be paid is above a predetermined 
amount. As a precaution some companies, when paying 
bills, may require a certain level of authority to approve 
payment if it is greater than a predetermined amount. The 
output module provides notification to the system user that 
this sort of authorization is required. If authorization is 
given, a further query is made through the GUI as to whether 
their authorization for this payment amount has been 
received. If the authorization is received, an invoice is 
created for payment and this is output from the system in 
hard copy form. In the final step of the process, the elec- 
tronic payment is transmitted to the vendor. This electronic 
payment may be either the fall amount originally charged by 
the vendor or a short pay amount which had been determined 
through the dispute tracking module. In the case where there 
has been a dispute and the bill has been short paid, the 
vendor receives the dispute report which then can be further 
negotiated with the customer at a later time. Once this 
dispute report is resolved, as was described above, the 
dispute report then can be closed as was described above. 

The foregoing description of the present invention has 
been presented for purposes of illustration and description. 
Furthermore, the description is not intended to limit the 
invention to the form disclosed herein. Consequently, varia- 
tions and modifications commensurate with the above 
teaching, and the skill or knowledge of the relevant art, are 
within the scope of the present invention. The embodiments 
described hereinabove are further intended to explain best 
modes known for practicing the invention and to enable 
others skilled in the art to utilize the invention in such or 
other embodiments and with various modifications required 
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by the particular applications or uses of the present inven- 
tion. It is intended that the claims be construed to include 
alternative embodiments to the extent permitted by the prior 
art. 

What is claimed is: 5 

1. An apparatus for processing billed charges from at least 
one vendor, comprising: 

a processor, comprising: 

an upload module which automatically uploads the 
billed charges from the at least one vendor in a first io 
format, wherein the billed charges include a plurality 
of entries with a billed rate component; and 

a database which includes reference billing rate infor- 
mation; and 

at least one graphical user interface in connection with the 15 
processor, wherein the graphical user interface is con- 
figured to received the billed charges, wherein the at 
least one graphical user interface includes: 
an automatic validation module which receives the 
billed charges and automatically compares the billed 2 o 
rate component of the plurality of entries with the 
reference billing rate information to identify discrep- 
ancies: 

a dispute tracking module which generates at least one 
dispute file which may be associated with a particu- 2 5 
lar one of the billed chargers, where the graphical 
user interface provides for display of both the billed 
charges and the at least one distpute file which is 
storable in and retrievable from the database; and 

a bill review and approval module which is operational 30 
in conjunction with a visual display which provides 
for selective accessing of and review of the billed 
charges and the associated at least one dispute file, 
and status changes relating to pavement of the billed 
charges, where the graphical display is fiber config- 35 
ured to receive input with regard to the billed 
charges, wherein the input includes at least one of: 
approve the billed charge and reject the billed 
charge. 

2. The apparatus of claim 1, wherein the processor is a ^ 
UNIX server. 

3. The apparatus of claim 1 wherein the processor is 
connected to the at least one graphical user interface through 
a connection over a data network. 

4. The apparatus of claim 3 wherein the connection is a 45 
ODBC TCP/IP connection. 

5. The apparatus of claim 1 wherein the database is 
relational in nature. 

6. The apparatus of claim 1 wherein the at least one 50 
graphical user interface is a computer workstation. 

7. The apparatus of claim 1, further including at least one 
processing module from a group comprising: 

a bill review and approval module which provides for 
review of the information relating to the billed charges, 55 
and status changes relating to payment of the billed 
charges. 

8. The apparatus of claim 7 wherein the automatic vali- 
dation module, the dispute tracking module, and the bill 
review and approval module are part of a software package 60 
loaded on the at least one graphical user interface. 

9. The apparatus of claim 8 wherein automatic validation 
module is programmable through the user interface to 
include custom criteria for identifying the discrepancies. 65 

10. The apparatus of claim 1 wherein the processor further 
comprises an output module which provides for automated 



,726 

14 

payment to the at least one vendor for the billed charges 
which have been approved. 

U. The apparatus of claim 10 wherein the output module 
is in connection with output means which provides invoices 
for the approved billed charges and dispute reports to the at 
least one vendor. 

12. A system for processing billed charges from a vendor 
comprising: 

a processor which provides automated uploading of the 
billed charges, storage of the billed charges and refer- 
ence information in a database, and outputting of 
payment information related to the billed charges; 
a user interface which includes means for automatically 
validating the billed charges with regards to the refer- 
ence information, generating at least one dispute report 
related to the billed charges, associating the at least one 
dispute report with the billed charges and providing for 
storage of the dispute reports in the database, and 
providing for a visual review of the billed charges with 
respect to any of the associated dispute reports, as well 
as disposition of the billed charges in response to a 
received input through the user interface; and 
a data network which provides communication between 
the user interface and the processor. 

13. The system of claim 12 wherein the processor 
includes an upload module which automatically uploads the 
billed charges from the vendor, converts the billed charges 
from a first format to a second format, checks integrity of the 
billed charges, scans the reference information for dupli- 
cates of the billed charges, and stores the converted billed 
charges in the database. 

14. The system of claim 12 wherein the processor is a 
UNIX server. 

15. The system of claim 12 wherein the user interface 
includes an automatic validation module which automati- 
cally retrieves the billed charges from the database and 
identifies discrepancies between the converted billed 
charges and the reference information. 

16. The system of claim 12 wherein the automatic vali- 
dation module is programmable through the user interface to 
include custom criteria for identifying the discrepancies in 
the billed charges. 

17. The system of claim 16 wherein the custom criteria 
include at least one of: contracted rates, tariffs, and rates 
established by third parties. 

18. The system of claim 12 wherein the user interface is 
a computer workstation. 

19. The system of claim 12 wherein the invoices and the 
dispute reports are displayed on the user interface according 
to a hierarchal structure. 

20. The system of claim 19 wherein information included 
in the invoices is transferable to the dispute reports by 
employing a drag and drop function. 

21. The system of claim 12 wherein the processor further 
includes an output module which provides for automatic 
payment to the vendor of the billed charges which have been 
approved. 

22. The system of claim 21 wherein the output module 
further includes means for automatically requesting 
approval when the billed charges are above a predetermined 
amount. 

23. The system of claim 12 wherein the user interface 
provides functionality to perform at least one of: view the 
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billed charges, view the dispute reports, selectively associate 
the invoices with the dispute report, search the invoices, 
search the dispute reports, search for vendor information, 
and search for account information. 

24. The system of claim 23 wherein the functionality is 
provided through screen displays presented on the user 
interface. 

25. The system of claim 1 wherein the billed charges 
relate to usage of telephone lines and the reference infer- 10 charges, tariffs 
mation relates to agreements between parties relating to use 
of the telephone line. 



26. The system of claim 25 wherein the reference infor- 
mation includes at least one of: circuit validity, circuit 
charges, tariffs. 

27. The system of claim 11 wherein the billed charges 
relate to usage of telephone lines and the reference infor- 
mation relates to agreements between parties relating to use 
of the telephone line. 

28. The system of claim 27 wherein the reference infor- 
mation includes at least one of: circuit validity, circuit 
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ABSTRACT 



A method and apparatus for authenticating transactions 
accomplished over a data network utilizes a "cookie" con- 
taining both static information (user-identifying 
information) and dynamic information (transaction-based 
information). The transaction-oriented dynamic information 
portion comprises a random number and a sequence number, 
the latter tracking the number of billing transactions con- 
ducted by the user associated with the account number. The 
cookie, sent to the user's cookie file upon a previous 
transaction, is valid for only a single new transaction. A 
billing server, upon receiving the cookie containing the 
static and dynamic information portions, identifies the user 
from the account number in the static portion and accesses 
from an associated database the expected random number 
and sequence number that the billing server last sent to that 
user in the transaction-oriented dynamic portion. If the 
expected dynamic portion matches the received dynamic 
portion, the user is authenticated to proceed with the current 
transaction, 

24 Claims, 3 Drawing Sheets 
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METHOD AND APPARATUS FOR BILLING billing server then cross-references the IP address associated 

FOR TRANSACTIONS CONDUCTED OVER with the cost of the transaction received from the merchant's 

THE INTERNET server with the IP- address/user-identity relationship 

received from the LAP to properly charge an established 
TECHNICAL FIELD 5 account of the user for the transaction. Such an account is 
TMs invention relates to billing a user for transactions for «t*liahcd by the user prior to the execution of the trans- 
services and/or goods provided and/or ordered over the f 1011 fo / bJ1 ! n S * a Predetermined manner to for example, 
Internet uscr s selectc " crecn t card, the user's debit card, the 

user's telephone account associated with his or her phone 

BACKGROUND OF THE INVENTION 10 number, the user's merchant credit card, or other billing 

^ t . . mechanism. For this billing methodology, arrangements thus 

u n "^ C ^^f^^^ 0 ^^-^ merchants need 5e betweeD billing and me , 

on the Worldwide Web (WWW) are becoming increasingly number of different Intemet Access Prov i ders that provide 

more numerous as the public becomes more facile in making Internet access t0 a tremendously large customer base since 

purchases on the Internet. Such transactions can be for the l5 for each mGT > s gesa ^ n me must be pr0 g ramme d to 

purchase of "soft" goods, i.e., information, software and forward t0 tne appropriate billing server the relationship 

other material available in electronic form that can be bet ween the user's currently assigned IP address and iden- 

dehvered in real time to a user's client terminal. Such ^ 

transactions can also be for the purchase of conventional A k;n . „ + u * * • • *u ♦ *u > a 

«u„ a» a u *u ■ j . j 1 . A billing methodology that minimizes the steps that need 

hard goods, where the purchased merchandise are dehv- on , * & < . u* • ,i_ • *■ j 1 c 

*~a „ff 1 r * be performed to obtain authorization and approval for an 

ered off-line. Conventional on-line payment options gener- * . . . .. P , . ,. 1t . 

oii„; mm i,»4h a »r. A r A tr a u *u a Internet transaction is therefore desirable. Further, a billing 

ally involve the use of credit cards wherein the user provides . , tL , . . A A . , , 1 

u. u ~ ~A't a u i- «i- * *u methodology that requires interactions between only the 

nis or her credit card number on-line or off-line to the , 4 M , ., ■ . 

„ „u * • j . r „ u ,„ „ C4 „ , user, the merchant, and the provider of the billing service is 

merchant provider to pay for the "hard or soft purchase , r 6 

to be delivered on-line or off-line. 25 * 

Where the transactions involve a relatively small cost, for SUMMARY OF THE INVENTION 

example $10 or less, the credit card system of payment is too A subscribing user who has registered with the provider of 

expensive. Further, the credit card payment system excludes the billing system of the present invention may browse the 

potential customers who do not have a credit card, or those home page of a merchant which has itself made previous 

who do but do not "trust" either providing their credit card 30 arrangements with the provider of the billing system. While 

number on-line, or do not want to use their credit card for "visiting 1 ' the merchant's site, which has also registered with 

such purchases. It would be advantageous, therefore, that the billing system, the subscribing user is offered the option 

some trusted transaction intermediary perform the functions to purchase some good or service at a stated price for either 

of authenticating a user on the WWW and authorizing the on-line or off-line delivery. In response to the user's intent 

transaction. Once such a transaction intermediary authenti- 35 to purchase the selected item and be billed via the billing 

cates the user and authorizes the transaction, the merchant is system, the merchant's digitally signed order is sent to the 

alerted to provide the goods or services which are the subject biUing system for authentication and authorization of the 

of the transaction and an account associated with the user is transaction. Specifically, in accordance with the present 

billed for the transaction amount. Advantageously, once the invention, information previously provided to the user's 

user has registered with the transaction intermediary, no 40 client terminal's cookie file is transmitted to a billing server 

sensitive billing information, such as a credit card number, within the billing system. This information comprises a 

needs to be sent to the merchant. stat i c information portion and a transaction oriented 

In co-pending application Ser. No. 08/532,336 filed Sep. dynamic information portion, which are encrypted prior to 

22, 1995 by Y. Ronen, co-inventor herein, and assigned to transmission. The static information portion identifies the 

the same assignee as the present application, a method of 45 user through an assigned account number. The transaction 

billing for services and/or goods ordered over the Internet oriented dynamic information portion comprises at least one 

from a merchant is disclosed. As described therein, the sequence that was sent to the user's cookie file by the billing 

customer/user places a real or a virtual telephone call to the server upon a previous transaction, and is valid for only a 

merchant's 900 telephone number and is charged by the single new transaction. The billing server, upon receiving 

telephone company an amount for that call that is represen- 50 from the user's browser program the cookie containing the 

tative of the cost of the goods or services being ordered via encrypted static and dynamic information portions and 

the Internet from the merchant's server. The merchant's decrypting same, identifies the user from the static portion, 

server associates the 900-number telephone call with the and accesses from an associated database the expected 

request via the Internet for the goods or services in order to transaction oriented dynamic portion that the billing server 

authenticate and authorize the transaction. In co-pending 55 last sent to that user. If the expected dynamic portion 

patent application Ser. No. 08/636,109 filed Apr. 22, 1996, matches the received dynamic portion, the user is authenti- 

co-invented by the same Mr. Ronen who is co -inventor cated to proceed with the current transaction. The billing 

herein, and assigned to the same assignee as the present server, upon authentication of the user, then authorizes the 

application, a method of billing for transactions conducted specific transaction based on various criteria such as the 

over the Internet is disclosed in which a billing server 60 user's credit limit, the cost of the transaction, etc. The billing 

connected on the Internet receives the IP address assigned to server then sends to the user's browser a new cookie which 

that user's client for the current user session and an indica- contains the user's account identity in the static information 

tion of the user's identity from the user/customer's Internet portion and a new transaction oriented dynamic portion to be 

Access Provider (IAP). In response to a chargeable used by the user's browser for authentication of the user for 

transaction, the merchant's server transmits to a billing 65 a next transaction. Upon receipt, the user's browser program 

platform the IP address identity of the user making the installs the new cookie and provides the user the opportunity 

transaction and the cost associated with the transaction. The to reject or finally approve of the transaction. If approved by 
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the user, the order is sent to the merchant's server via the 
user's client terminal browser program. Upon receipt, the 
merchant's server posts the complete transaction informa- 
tion to the billing server for billing and provides for the 
delivery of the goods or services to the user. The customer's 
transaction is then confirmed through an acknowledgment 
sent via e-mail transmitted to the e-mail address associated 
with the account number. The billing server either after each 
transaction, or on a periodic basis, sends the transaction 
summary to a billing platform for billing of the user based 
on his or her registered billing preference such as a tele- 
phone bill, credit card charge, or a direct invoice. The billing 
platform then settles with the merchant after a fixed number 
of days, contingent on the user paying his or her bill. 

In the specific embodiment of the present invention, the 
transaction oriented dynamic information portion of the 
cookie comprises a random number and a sequence number 
that are both assigned by the billing server. After each 
transaction, a random number is created by the billing server 
and sent back to the user's client terminal for use for the next 
transaction together with a sequence number that tracks the 
number of separate billing transactions conducted by the 
user associated with the static account number. The latter is 
incremented by one after each transaction. Both the random 
number and the sequence number are stored in a database 
associated with the billing server in a record associated with 
the user's account. As noted, the cookie is valid for only a 
single transaction. If a user's cookie file should be misap- 
propriated from the user's client terminal or is intercepted 
during transmission from the billing server to the client 
terminal and is fraudulently used, a subsequent use by the 
actual registered user will cause the billing server to reject 
the user's cookie. The billing server will then request an ID 
and a password from the user for user authentication. By 
comparing the sequence number of the cookie received from 
the actual user with the sequence in the cookie stored in the 
billing server, a determination of which transactions are 
fraudulent made can be made. A new cookie containing a 
new random number is then placed by the billing server in 
the user's cookie file, thereby precluding further fraudulent 
use by the misappropriating cookie thief. 

Advantageously, the authentication of a user making a 
transaction in accordance with the present invention does 
not require installation of any special software on the user's 
client terminal other than a browser which supports cookie 
files. Furthermore, the user can be automatically identified 
by the billing system with the cookie without requiring the 
user to enter an ID or password for every transaction. Even 
furthermore, the user is able to retain his or her anonymity 
with respect to the merchant, which a user may be desirous 
of doing. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a system showing a billing 
system connected to the Internet for billing for transactions 
conducted by a user's client terminal with a merchant 
WWW server in accordance with the present invention; and 

FIGS. 2 A and 2B, referred to collectively hereinafter as 
FIG. 2, show the steps of a transaction flow involving the 
client terminal, the merchant server and the billing system in 
accordance with the present invention. 

DETAILED DESCRIPTION 

With reference to FIG. 1, a user at a client terminal 101 
is connected to the Internet 102 through an Internet Access 
Provider 103. The connection between the client terminal 
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101 can be, for example, through a Local Exchange Carrier 
(LEC) (not shown), through a cable TV network (not 
shown), or through another access medium. The client 
terminal 101 could also be connected directly to a Local 

5 Area Network which is directly connected to the Internet 
102. The client terminal 101 runs a browser program which 
enables the user to "surf the Net" to visit various sites 
connected to the Internet. Some of these sites only provide 
information content and other sites may provide information 
in conjunction with offers of services and/or "soft" or "hard" 
goods with an associated cost. The services for a fee may 
include the delivery to the user of information itself, or the 
delivery of "soft" goods that can be delivered digitally 
on-line over the Internet to the client terminal, such as 
software, music, video, etc. If the user orders "hard" goods 

15 over the Internet, as for example clothing, delivery need 
obviously be made off-line. Some of these transactions that 
involve the delivery of information or a software program 
may have a relatively low cost to associated with them. 
Further, a user may visit such an on-line merchant's site only 

20 once or very infrequently. The present invention eliminates 
the need for the user to establish a financial relationship with 
the on-line merchant who is supplying the soft or hard goods 
that are the subject of the transaction. Thus, the user need not 
provide any financial information, such as a credit card or 

25 other personal information to the merchant to be assured 
initiation of the delivery process for the desired soft or hard 
goods or services. Accordingly, a user who has registered 
with the billing system 104 of the present invention and who 
enters into an on-line transaction with a registered merchant 

30 can obtain the transacted-for hard or soft goods or services 
without having to provide any personal information to the 
merchant, including his or her identity. The merchant, hav- 
ing registered itself with the billing system, can also be 
assured of receiving payment from the trusted provider of 

35 the billing system since it knows that each transaction will 
be user-authenticated and authorized by the billing system. 

In order to conduct on-line transaction through the billing 
system 104, the user needs to register with the system. This 
registration occurs at the user's initiative, by posting infor- 

40 mation via the Internet to a registration server 105 within 
billing system 104 or by paper (e.g., fax or mail), or by 
telephone. The registration process occurs once per user. The 
process allows a user to establish an account, which requires 
a billing name, address, e-mail address, and billing prefer- 

45 ences for charges made to the account. The latter may 
include a direct bill to an email address or to the postal 
address associated with the user's telephone number, or to a 
telephone bill (LEC or Interchange carrier), or to a user's 
credit card or debit card. These preferences can be distrib- 

50 uted amongst different billing mechanisms as a function of 
the type of transaction being billed. Thus, the user can direct 
that all transactions of less than a predetermined cost be 
billed to his or her telephone bill, and those of greater than 
that cost be billed to his or her credit card. Also, the user can 

55 direct transactions of a certain type, such as purchases of 
software to be direct-billed and other types be billed accord- 
ing to the cost of the goods as noted above. Other informa- 
tion unique to the user, such as a password, is also obtained 
in the registration process that can be later used to validate 

60 the billing information. The information can be updated 
when the user's billing information changes, or additional 
users need to added/removed from an specific account. If 
entered on-line through registration server 105, the infor- 
mation is stored in a database 106 for later retrieval. If 

65 received from the user by another methodology, the infor- 
mation is entered by an operator associated with the billing 
system 104 and stored in database 106. 



01/09/2003, EAST Version: 1.03.0002 



6,047, 

5 

Upon activation of the account, the billing server assigns 
and deposits a cookie on the browser program running oo 
user's client terminal 101, which in turn transmits it back to 
the billing system 104 during the course of a transaction. 
Cookies are well known in the art. Cookies are described, for 5 
example, in Netscape Support Documentation found on the 
Internet at http:/home.netscape.com/newsre£/std/cookie_ 
spec.html. The cookie is sent to the client by including a 
Set-Cookie header as part of an HTTP response. The Set- 
Cookie is sent by the billing server 107 and is generated by 10 
a CGI script in the following format: 
Set-Cookie: NAME-VALUE [;expires=DATE][;path= 

PATH] 

[;domain=DOMAIN_NAME][;secure] 
The cookie is stored in a text file (e.g., Netscape cookie.txt 15 
file) on the client terminal 101 and is sent to the originating 
billing server 107 to its domain when the client terminal 
makes a request to DOMAlN_NAME, specifically the URL 
associated with the billing server 107. Although the 
Netscape browser uses one data file for all cookies, with one 20 
line being used per cookie in the file, other browser such at 
MS Internet Explorer, use a separate data file for each 
cookie. For either, the cookie remains valid until its expi- 
ration on DATE. In accordance with the present invention, 
the cookie VALUE is an encrypted string that comprises in 25 
its decrypted form a static information portion and a 
dynamic information portion. The static portion is an alpha- 
numeric string identifying the user's account number as it is 
stored in database 106. The dynamic portion includes a 
random number generated by the billing server and a 30 
sequence number that is stored in database 106 in associa- 
tion with the user's account number. That sequence number 
is initialized at one (or any other value) when the user first 
registers with the billing platform and is subsequently incre- 
mented by one (or any other positive or negative predeter- 35 
mined number or algorithm) each time the user makes a 
separate transaction. The cookie thus initially deposited by 
the billing server 107 into the user's cookie file in its 
decrypted form thus contains a string comprising the user's 
account number, a random number generated by the billing 40 
server 107, and a sequence number having a value of one. 
The billing server stores the generated random number and 
the sequence number in database 106 in a record associated 
with the user's account number that has been created. 

As the user on client terminal 101 subsequently "surfs the 45 
Net", he or she will link to the home page of various 
merchants' servers 108 and 109. When linking to the home 
page of a particular merchant's server 108 which has entered 
into a billing agreement with the provider of the billing 
system 104, the user is offered the option to purchase some 50 
item at a stated price using the payment option provided by 
the subscribed- to billing system 104. When the user clicks 
on an order page, representing the intent to purchase the 
selected item and to be billed through the billing system 104 
via his or her account established therein, the merchant's 55 
signed order is sent to billing system 104 for authentication 
of the user and authorization for the transaction. At the same 
time the information stored in the cookie file on the user's 
client terminal is transmitted to billing server 107. 

The user is then authenticated by the billing system 104 60 
using the information in the received cookie. Specifically, 
the received cookie is decrypted and the VALUE of the 
decrypted cookie received by the billing server is parsed into 
the static user account identity portion and the dynamic 
random number and sequence number portions. The identity 65 
of the requesting user is determined from the account ID in 
the static information portion of the VALUE string. The 
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random number and the sequence number in the dynamic 
information portion are then compared with the random 
number and the sequence number stored in database 106 for 
the record associated with the determined account number. 
If a match is made, the user is authenticated for the trans- 
action. 

There may be cases when the cookie cannot be used. The 
cookie may have been expired, or a cookie file in a user's 
browser program may have been erased, or the browser 
program may have disallowed the writing into a cookie file. 
Also, there may be other legitimate reasons in which there 
is not a match between the cookie sent from the user's client 
terminal to the billing server and the cookie stored in the 
database 106 for that user. The latter could arise when the 
user uses another browser to make an on-line billing system- 
billed purchase from a client terminal other than the one in 
which the cookie was originally deposited. In any such cases 
in which a cookie match cannot be made, the user is 
prompted for a login name and a password, which are 
chosen by the user during the registration process. If the 
billing system detects that the cookie information is 
incorrect, but the user has correctly provided the login name 
and password, the billing system will deposit a cookie on the 
user's browser. However, to ensure that the user is aware that 
a cookie is being deposited, and that it can provide automatic 
authentication for a subsequent billing system-based pur- 
chase from that browser on that client terminal, the billing 
system posts a message to the client terminal requesting the 
user to affirmatively acknowledge, through an interactive 
click, that they wish to save their billing system account 
information on that client terminal for subsequent transac- 
tions. 

There may also be situations in which the user may find 
it desirable to and force the entry of an ID and a password 
for each transaction to provide added security. Such a 
situation may arise when multiple users share a common 
client terminal, as in a household. Thus, by providing the 
user with the option to disable the cookie, the user will be 
forced to enter an ID and a password for transaction authen- 
tication. 

If the cookie provided to the billing system from the 
user's client terminal does not match the cookie stored in the 
database 106 for the requesting user, a possibility exists that 
a fraudulent use of the user's account has been made by 
someone who has misappropriated the user's cookie from 
either the client terminal's cookie file, or through on-line 
eavesdropping of the transmission of the cookie to the client 
terminal. If the cookie has been stolen and used to make a 
fraudulent transaction, the thief may have been able to make 
successive such transactions by receiving a new cookie after 
each transaction that would enable a next transaction to be 
made. Each such fraudulent transaction will generate a new 
cookie with a new random number and an incremented 
sequence number. When the legitimate user attempts to later 
make a transaction, the cookie then stored in his or her client 
terminal's browser program will no longer match the cookie 
stored in database 106 for that client. The user will thus be 
initially rejected but will be authenticated through the input 
of a valid account number and password. By comparing the 
sequence number of the cookie then stored in database 106 
for that user's account with the sequence number of the 
cookie in the cookie file stored in the user's client terminal, 
the identity and the number of fraudulent transactions can be 
determined. Thus, for example, if the sequence number of 
the user's cookie is 27 and the sequence number in the 
cookie stored in database 106 for that user's account is 30, 
then the last three transactions were fraudulently made to the 
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user's account assuming that each transaction increments the 
sequence number by one. Once such a fraud has been 
detected, a new cookie is deposited in the user's cookie file, 
thereby precluding further use by the thief of the misappro- 
priated cookie or its successively generated cookies. 

Assuming that the user has been authenticated, the trans- 
action needs to be authorized by the billing system. When 
the user "clicks-to-buy", which is the stage in the merchant- 
user electronic shopping web interface when the user has 
confirmed a willingness to complete the transaction with the 
stated terms, the transaction must be authorized. The order 
information, digitally signed by the merchant is sent through 
the user's client terminal's browser to the billing system 
104. The order amount, combined with the cookie file 
containing the user's account ID number and transaction 
number, provide sufficient information to query the user's 
profile stored in database 106 to verify if the transaction 
should be authorized. Authorization for the transaction will 
be granted if (1) the user is registered as active in the billing 
system; (2) the merchant is registered with the billing 
system; (3) the user is not blocked from making purchased 
based on payment history; (4) the purchase amount does not 
exceed a per- transaction limit specified by the user upon 
registration; (5) the purchase amount does not exceed the 
billing system's specified cumulative credit limit; and (6) the 
purchase does not violate any customer-specified restrictions 
(e.g., block transactions during certain times) or preferences 
(e.g., block transactions for certain types of merchandise). If 
authorization is denied, a message is displayed on the user's 
browser indicating that the purchase cannot be authorized 
and inviting the user to contact a customer assistance 
representative at a specified phone number. Additional cri- 
teria can also be used to determine whether or not to 
authorize a specific transaction. 

After the user has been authenticated and the transaction 
authorized, an authorization token, which is the digital 
signature of the order created by the billing system 104 using 
its private key, along with the order form encrypted using the 
merchant's public key, is generated by the billing system and 
sent to the user's browser together with a summary of the 
order and the charges for final approval by the user of the 
charges. The user can retain the authorization token for later 
proof of the order and charges. Also sent to the user's 
browser by the billing server 107 is a new cookie having a 
VALUE field containing the static user's account ID infor- 
mation portion and a dynamic information portion compris- 
ing a newly created random number and an incremented 
sequence number. This new cookie is for use by the user's 
browser program for a next transaction. 

Following the user's final approval of the charges, which 
may occur by the failure of the user to affirmative cancel the 
order, the token and the order are sent to the merchant's 
server 108 via the user's client terminal's browser. Receipt 
of the authorization token verifies to the merchant that the 
transaction has been authorized by the billing system. Soft- 
ware running on the merchant server 108 verifies the autho- 
rization and delivers the requested goods to the user. This 
may happen in real time for "soft" goods. For "hard" goods, 
the merchant provides an acknowledgment to the user that 
the ordered merchandise is being shipped or the order has 
been processed. For "soft" goods, the merchant's server 108 
posts the complete transaction information (i.e., authoriza- 
tion token, order information) to the billing system 104 for 
billing by a billing platform 110. For "hard" goods, certain 
state and federal regulations may require that for some types 
of merchandise the transaction cannot be posted until the 
goods are shipped, while others (e.g., catalog sale of goods) 
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are permitted to post after the order is accepted. The billing 
server 107 sends the transaction information, appropriately 
formatted to the billing platform 110 for billing the user 
based on the user's billing preferences as stored in database 
106. Upon payment of the bill by the user, the billing system 
settles with the merchant. 

At the end of the user's Internet session, or periodically if 
there is any activity related to the user's account, the billing 
system transmits an email summary to the account holder 
showing all the transactions conducted over a period of time. 
The information provided shows the transaction ID, the 
amount, date/time of purchase and merchant name. 

With reference to FIG. 2, the interactive steps are shown 
between a user at a client terminal browsing on the Internet 
and making an on-line purchase, the merchant server with 
which the transaction is made, and the billing system of the 
present invention which automatically authenticates the 
user, authorizes the transaction, and bills for the purchase. At 
step C201 the user browses the merchant's site and requests 
an order form for ordering some good from the merchant. At 
step M201, the merchant's server responds by sending the 
requested order form to the client terminal. At step C202, at 
the client terminal the user fills in the order form, optionally 
may select a billing method, and submits the tentative order 
back to the merchant. The merchant then must verify the 
order (availability, pricing, etc.) and calculate a final price. 
The merchant at this stage does not have a valid transaction 
number from the billing system, nor the user's account ID on 
the billing system. At step M202 the merchant constructs a 
message consisting of: a merchant ID, a time-stamp, an 
optional merchant transaction ID or order number, a trans- 
action amount, and optional other order data such as type of 
request and expiration date for an offer. The message is 
hashed into a digest and signed by the merchant's private 
key. The message data, signature, and merchant's certificate 
are wrapped and encrypted and returned to the client with a 
request for confirmation of the order. At step C203, the user 
confirms the order by a "click-to-buy" input for which an 
icon is provided on the HTML page returned to the client 
and which provides a link to the billing system. When the 
user clicks on this icon, the request for authorization is 
routed to the billing system over a Secure Socket Layer 
(SSL) link, in which the merchant's signed order is embed- 
ded. In addition, the cookie stored in the user's cookie file 
on the browser program is sent to the billing system as well. 
The billing system, upon receiving the cookie and the order 
information will first authenticate the user. At step B201, a 
determination is made whether a cookie is received. If a 
cookie is not received, the process proceeds to step B205 
where a determination of whether a user ID and a password 
have been received. If yes, at step B206 a determination of 
whether that ID and password are valid is made. If not, at 
step B207, a message is sent back to the client terminal to 
inform the user at step C205 that they have not been 
authenticated and to call a customer assistance number. If a 
valid ID and password are found at step B206, the process 
passes to step B208 where transaction authorization will 
take place. If neither a cookie is received at step B201, nor 
an ID and a password are received at step B205, then the 
billing system sends a request back, at step 203, to the client 
requesting an ID and a password. Similarly, if a cookie is 
received at step 201, at step B202, the received cookie is 
compared with the cookie stored in the billing system for the 
user identified from the static information portion of the 
cookie. If a match is made, the user is authenticated and the 
process passes to step B208 for transaction authorization. If 
a match is not made at step B202, then the process passes to 
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step B203, where the billing system issues a message 
requesting an ID and a password from the user. In response 
to the request for a user ID and password from step B203, 
generated in response to either steps B205 of 6202, at step 
C204 the user enters his or her ID and password and enters 5 
a "click-to-buy" input again. If a valid password and ID are 
returned, the process passes through steps B201, B205, and 
B206 for authorization at step B208. [f a valid password and 
ID are not returned, then the process passes through steps 
B201, B205, B206 and B207 to send a message of non- 10 
authentication to the user attempting to make the transac- 
tion. 

At step B208, a determination is made whether the 
transaction is authorized. To do this, the encrypted message 
containing the original order, the merchant's signature and 15 
the certificate are decrypted. The billing system then deter- 
mines whether the transaction can by authorized. As previ- 
ously noted, a transaction is authorized if the user is regis- 
tered in the billing system database, the merchant is 
registered with the billing system, the user is not blocked 
from making purchases based on payment history, the pur- 20 
chase amount does not exceed a per-user specified limit, and 
the purchase does not violate any customer-specified restric- 
tions or preferences. If the transaction is not authorized, at 
step B209, a message is returned to the merchant through the 
user's browser indicating that the transaction was unable to 25 
be authorized. At step C206, the user receives the message 
with directions to call a specified customer assistance num- 
ber for further information. 

If the transaction is authorized at step B208, at step B210 
an authorization response is prepared for transmission to the 30 
user for final approval of the transaction and then for 
forwarding, upon such approval to the merchant. The billing 
system adds a transaction ID, an authorization time-stamp, 
an authorization code, and an authorized transaction amount, 
together referred to as the authorized transaction data. The 35 
authorized transaction data, the billing system signature and 
certificate are then encrypted. In addition, a new random 
number is created and the sequence number is incremented 
to create a new cookie, which is sent back to the user with 
the encrypted transaction and signature over a SSL link. At 
step 207, the user is asked to accept the charges requested by 40 
the merchant. If accepted, the encrypted signed transaction 
data is sent to the merchant. The new cookie is also installed 
in the user's browser program. At step M203, the transaction 
data is decrypted and the signature verified. The transaction 
is then fulfilled either by the real-time on-line delivery of the 45 
goods or initiating processing for off-line delivery of the 
ordered merchandise. The transaction is recorded by the 
merchant and a bill request is posted to the billing system. 
At step C208, the user receives an acknowledgment that the 
order has been received and the content of the order, if the 50 
latter is delivered on-line. At step B211, the billing server 
processes the billing request, billing the user in accordance 
with the registered billing preference and sends an acknowl- 
edgment to the merchant that the user has been billed. At 
step M204, the merchant receives that acknowledgment and 55 
later receives payment from the billing system for the goods 
provided to the user. 

Although described above in conjunction with the deliv- 
ery to the user of goods after billing has been effected, the 
present invention could equally apply to a scenario in which 
the goods are delivered to the user on-line before payment 60 
is made, such as for shareware. In this scenario, the mer- 
chant first downloads the goods to the user and then offers 
the user to pay with the direct billing payment option of the 
present invention. Alternatively, the user can be authorized 
to make purchases for a specific dollar amount, before any 65 
items are selected for purchase, and the customer is then 
allowed to browse and choose items for purchase up to the 
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authorized amount. After the user has selected all items, the 
actual dollar amount spent, which is less than or equal to the 
authorized amount, is posted to the billing system. 

Although described in conjunction with the authentication 
of a user for a transaction for the delivery of goods that is 
being conducted on the Internet, the principles of the present 
invention could be applied to the authentication of a user for 
any type of transaction that is being conducted over any type 
of data network. 

The above -described embodiments are illustrative of the 
principles of the present invention. Other embodiments 
could be devised by those skilled in the art without departing 
from the spirit and scope of the present invention. 

The invention claimed is: 

1. A method of authenticating a user for a transaction on 
a data network comprising: 

sending to a user's client terminal data containing a static 
information portion and a transaction-oriented dynamic 
portion, the static information portion identifying an 
account associated with the user and the transaction- 
oriented dynamic information portion containing infor- 
mation generated for that user that is valid for a single 
subsequent transaction; 

storing the transaction-oriented dynamic information por- 
tion in association with the static information portion; 

receiving, from the user's client terminal, the data con- 
taining the static information portion and the 
transaction-oriented dynamic information portion in 
association with information relating to the single sub- 
sequent transaction; 

identifying the user's account from the received static 
information portion; 

comparing the transaction-oriented dynamic information 
portion received from the user's client terminal with the 
transaction -oriented dynamic information portion 
stored in association with the static information por- 
tion; and 

authenticating the user for the single subsequent transac- 
tion if the received transaction-oriented dynamic infor- 
mation portion matches the stored transaction-oriented 
dynamic information for the account associated with 
the user. 

2. The method of claim 1 further comprising: 
creating a new transaction -oriented dynamic information 

portion; 

sending to the user's client terminal new data to replaced 
the previously sent data, the new data containing the 
same static information portion in the previously sent 
data and the new transaction-oriented dynamic infor- 
mation portion, the new transaction-oriented dynamic 
information portion being different than the 
transaction-oriented dynamic information portion in 
the previously sent data, the new data being valid for 
authenticating the user for a next single transaction; and 

storing the new transaction-oriented dynamic information 
portion in association with the same static information 
portion. 

3. The method of claim 2 wherein the transaction-oriented 
dynamic portion of the data previously sent to the user's 
client terminal and the new transaction-oriented dynamic 
information portion each comprise a random number and a 
sequence number. 

4. The method of claim 3 wherein the new transaction- 
oriented dynamic portion comprises a random number dif- 
ferent than the random number in the data previously sent to 
the user's client terminal and a sequence number that is 
equal to the sequence number in the data previously sent to 
the user's client terminal plus a predetermined increment. 
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5. The method of claim 1 wherein the data network is the 
Internet. 

6. The method of claim 5 wherein the data is contained 
within a cookie. 

7. The method of claim 1 wherein the static information 
portion and the transaction-oriented dynamic information 
portion of the data are encrypted. 

8. A method for authenticating a user for a transaction on 
the Internet comprising: 

sending to a user's client terminal a cookie containing a 
static information portion and a transaction-oriented 
dynamic portion, the static information portion identi- 
fying an account number associated with the user and 
the transaction-oriented dynamic information portion 
containing information generated for that user that is 
valid for a single subsequent transaction; 

storing the transaction-oriented dynamic information por- 
tion in association with the ^user's account number 
identified by the static information portion; 

receiving from the user's client terminal the cookie con- 
taining the static information portion and the 
transaction- oriented dynamic information portion in 
association with information relating to the single sub- 
sequent transaction; 

identifying the user's account number from the static 
information portion in the received cookie; and 

comparing the transaction-oriented dynamic information 
portion in the received cookie with the stored 
transaction-oriented dynamic information portion asso- 
ciated with the identified user's account number. 

9. The method of claim 8 further comprising authenticat- 
ing the user for the transaction if the transaction-oriented 
dynamic information portion in the received cookie matches 
the stored transaction-oriented dynamic information portion. 

10. The method of claim 8 further comprising: 

if the transaction-oriented dynamic information portion in 35 
the received cookie does not match the stored 
transaction -oriented dynamic information portion, 
requesting an account number and a password from the 
user 

receiving the account number and password from the user 40 
in response to the request; and 

if the received password matches a stored password 
associated with the user's account number, authenti- 
cating the user for the transaction. 

11. The method of claim 9 further comprising: 
creating a new cookie with a new transaction-oriented 

dynamic information portion and the same static infor- 
mation portion in the cookie previously sent to the user; 

sending the new cookie to the user's client terminal to 
replace the previously sent cookie; and 

storing the new transaction-oriented dynamic information 
portion in association with the user's account number. 

12. The method of claim 8 wherein the transaction- 
oriented dynamic information portion of the cookie com- 
prises a random number and a sequence number. 

13. The method of claim 12 wherein the sequence number 
in the transaction-oriented dynamic information portion of 
the new cookie is equal to the sequence number in the cookie 
previously sent to the user's client terminal plus a predeter- 
mined increment. 

14. The method of claim 8 wherein the transaction- 
oriented dynamic information portion and the static infor- 
mation portion of the cookie are encrypted. 

15. The method of claim 10 further comprising: 
if the received password does not match a stored pass- 
word associated with the user's account number, deny- 
ing the transaction. 
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16. The method of claim 8 further comprising: 

if the transaction-oriented dynamic information portion in 
the transition-oriented received cookie does not match 
the stored transaction-oriented dynamic information 
portion, denying the transaction. 

17. The method of claim 13 further comprising: 

if the transaction-oriented dynamic information portion in 
the received cookie does not match the stored 
transaction-oriented dynamic information portion, 
determining whether any fraudulent transactions were 
made on the user's account. 

18. The method of claim 17 wherein the step of deter- 
mining whether any fraudulent transaction were made com- 
prises: 

comparing the sequence number in the cookie received 
from the user's client terminal with the sequence num- 
ber in the stored cookie; and 

identifying fraudulent transactions from the difference 
between the sequence number in the cookie received 
from the user's client terminal and the sequence num- 
ber in the stored cookie. 

19. A system for authenticating a user for a transaction on 
the Internet comprising: 

means for sending to a user's client terminal a cookie 
containing a static information portion and a 
transaction-oriented dynamic information portion, the 
static information portion identifying an account num- 
ber associated with the user and the transaction- 
oriented dynamic information portion containing infor- 
mation generated for that user that is valid for a single 
subsequent transaction; 

means for storing the transaction-oriented dynamic infor- 
mation portion in association with the user's account 
number identified by the static information portion; 

means for receiving from the user's client terminal the 
cookie containing the static information portion and the 
transaction -oriented dynamic information portion in 
association with information relating to the single sub- 
sequent transaction; 

means for identifying the user's account number from the 
static information portion in the received cookie; and 

means for comparing the transaction-oriented dynamic 
information portion in the received cookie with the 
stored transaction-oriented dynamic information por- 
tion associated with the identified user's account num- 
ber. 

20. The system of claim 19 wherein the user is authenti- 
cated for the transaction if the transaction-oriented dynamic 
information portion in the received cookie matches the 
stored transaction-oriented dynamic information portion. 

21. The system of claim 20 wherein the transaction- 
oriented dynamic information portion of the cookie com- 
prises a random number and a sequence number. 

22. The system of claim 21 wherein the sequence number 
in the transaction-oriented dynamic information portion of 
the new cookie is equal to the sequence number in the cookie 
previously sent to the user's client terminal plus a predeter- 
mined increment. 

23. The system of claim 21 wherein the transaction- 
oriented dynamic information portion and the static infor- 
mation portion of the cookie are encrypted, 

24. The system of claim 19 wherein the transaction is 
denied if the transaction-oriented dynamic information por- 
tion in the received cookie does not match the stored 
transaction-oriented dynamic information portion. 
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ABSTRACT 



An integrated data processing system is described which 
comprises an execution control processor (10) that itself 
comprises a security processor (12) and data base processor 
(14). Bidirectional communication with a printer (30) is 
provided through a print processor (28) to provide for the 
secure printing of financial instruments. Grammar files (24) 
and parameter files (26) are supplied to allow for the 
configuration and customization of the execution control 
processor (10) and a graphical user interface (18). A com- 
munications processor (20) is provided to establish network 
connection with a host computer. Context-sensitive help is 
provided using a help processor (22). 

19 Claims, 8 Drawing Sheets 
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AUTOMATED FINANCIAL INSTRUMENT 
PROCESSING SYSTEM 

This application is a continuation of application Ser. No. 
08/173,907, filed Dec. 27, 1993, entitled "Automataed 
Financial Instrument Processing System," by Jeanne M. 
Custy, Benjamin L. Knoll, Shunsaku Suguira and Brian W. 
Walsh, now abandoned. 

TECHNICAL FIELD OF THE INVENTION 

This invention relates in general to data processing sys- 
tems and more particularly to an improved automated finan- 
cial instrument processing system and method of operation. 

BACKGROUND OF THE INVENTION 

Automated systems for printing and delivering money 
orders have been developed and used in the past with some 
measure of success by both financial institutions and retail 
outlets. These systems provide the basic systems and meth- 
ods of providing the transaction data to a printer which holds 
blank financial instruments such as money orders. The blank 
money orders are stored in the printer in a secure fashion to 
prevent fraudulent creation of money orders. The presence 
of blank money orders in the printer makes the system very 
vulnerable to the fraudulent creation of money orders and to 
mistakes in the creation of money orders such as the creation 
of duplicate money orders due to printer malfunctions, user 
data entry errors or other system malfunctions. 

The systems that have been developed for creating and 
delivering money orders in the past have been systems with 
dedicated hardware and little, if any, interface with other 
systems such as general accounting systems, other data 
processing facilities or back-up and recovery facilities. Inte- 
gration of the delivery and creation of financial instruments 
is necessary to provide adequate security for these facilities 
and to allow for communication of these subsystems with 
supervisory systems such as host accounting systems. 

SUMMARY OF THE INVENTION 

Accordingly, a need has arisen for an integrated financial 
instrument processing system that is generally portable to a 
variety of platforms and hardware architectures and provides 
adequate security during the creation and delivery of finan- 
cial instruments. In accordance with the teachings of the 
present invention, an integrated financial instrument pro- 
cessing system is provided that substantially reduces disad- 
vantages associated with prior art systems and methods of 
operation. 

According to one embodiment of the present invention, a 
financial instrument processing system is provided that 
comprises a graphical user interface that is operable to 
communicate with a data base processing system. The 
graphical user interface and data base processing systems 
are monitored by a security processor which provides secu- 
rity for the system on a user-by-user and object-by-object 
basis. A printer is coupled to the print processing system and 
is operable to print financial instruments using information 
sent from the execution control processor. The print proces- 
sor monitors printer messages and communicates with the 
security processing system to prevent unauthorized access to 
the printer. After receiving verification that the financial 
instrument has printed, the print processor passes transaction 
information to the data base processor. The information is 
then written to the transaction file. 

According to another embodiment of the present 
invention, a communications processor is included and is 
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operable to communicate with the data base processing 
system to provide information stored in the data base 
processing system to other systems such as host accounting 
systems. 

5 According to an alternate embodiment of the present 
invention, a grammar file is provided that is operable to 
revise constants in the graphical user interface on a user- 
by-user basis. A parameter file is also provided to configure 
the general operation of the financial instrument processing 

10 system. 

According to an alternate embodiment of the present 
invention, the software system of the present invention 
serves as an open platform to allow for the integration and 
processing of other financial applications or products. For 

15 example, the modular nature of the system of the present 
invention allows for the efficient integration and manage- 
ment of other products such as money grams, starter checks, 
variable amount coupons, gift checks or gift certificates, 
cashier checks, insta-pay functions, phone cards and the 

20 like. In addition, the modular nature of the system of the 
present invention allows it to be integrated with other teller 
applications. For example, the functions of the present 
system can be accessed through an alternate working envi- 
ronment that would replace the graphical user interface of 

25 the present invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the present invention 
30 may be acquired by referring to the accompanying FIG- 
URES in which like reference numbers indicate like features 
and wherein: 

FIG. 1 is a schematic block diagram of the financial 
instrument processing system constructed according to the 
35 teachings of the present invention; 

FIGS. 2 through 28 comprise menu and flow chart rep- 
resentations of the financial instrument processing method 
of the present invention. 

40 DETAILED DESCRIPTION OF THE 

INVENTION 

The financial instrument processing system of the present 
invention comprises an object-oriented software system that 

45 is highly portable between various hardware platforms. The 
architecture of the integrated software system is constructed 
such that the system can be easily and conveniently ported 
to a variety of operating systems such as MS DOS, 
Windows, OS2, or UNIX. In addition, the system of the 

50 present invention is highly adaptable to network environ- 
ments such as local area networks, wide area networks, 
mini -LANs and the like where the various components can 
be resident in physically separated servers. The architecture 
of the present invention is illustrated in FIG. 1 and com- 

55 prises an execution control processor 10 which itself com- 
prises a security processor 12 and a data base processor 14. 
The data base processor also comprises a report writer 16 
and accesses data stored in transaction files 17. It should be 
understood that the term processor used herein refers to a 

60 software module operating to perform a particular task or 
group of tasks. A single such module may actually be 
running on a variety of hardware architectures which could 
include single or multiple hardware processors. 
The data base processor 14 manages an ASCII flat file 

65 data base which uses relative record key accesses to provide 
for efficient storage and maintenance of the data used by the 
integrated system. The ASCII files are stored in transaction 
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files 17 and accessed as necessary by the data base processor user's security level. Further, the security processor 12 

16. In one embodiment of the present invention, ASCII flat requires entry of a password or other security measures 

files are used to maintain portability between various, before the integrated system is allowed to progress through 

platforms and their operating systems. ASCII flat files are a particular object. 

accepted without compatibility concerns by virtually all 5 The execution control processor 10 is also coupled to a 

hardware platforms. According to alternate embodiments of communications processor 20. The communications proces- 

the present invention, other more sophisticated data base sor 20 allows the integrated system to communicate with 

systems may be used such as SYBASE or ORACLE pro- other systems through network connections. According to 

vided that a particular hardware platform and operating one embodiment of the present invention, the communica- 

environment to be used is compatible with such data base J(J tions processor 20 allows for communication with an inte- 

systems. More sophisticated data base products provide for grated communications platform system to allow for 

intrinsic journaling, intrinsic mirroring and intrinsic data session-based communications with a host computer. The 

base recovery which may be advantageously used in the operation of such a communications platform is fully 

architecture of the present invention. described in U.S. patent application Ser. No. 08/130,297 

The data base processor 14 records the transactions per- 15 entitled "INTEGRATED COMMUNICATIONS PLAT- 

formed by the integrated system in a largely chronological FORM" filed Oct, 1, 1993 now abandoned, and assigned to 

order, including audit information such as a teller perform- the Assignee of the present application, the disclosure of 

ing the transaction, and the date and time of the transaction. which is hereby incorporated by reference into the present 

The relative record key access system used by the data base description as if set forth fully herein. The integrated system 

processor 14 allows for an access to be performed within the 20 of the present invention allows the user to perform a variety 

data base processor 14 by jumping to the date of the of transactions which are logged in the data base of infor- 

transaction or record desired and then providing sequential mation managed by data base processor 14. Periodically, 

access through the group of records associated with that these transactions may be uploaded to a host computer or 

date. In order to provide for the fastest access, the records super server through the communications processor 20. In 

are accessed within the date in reverse chronological order. 25 addition, a variety of maintenance and supervisory opera - 

This access method is used because, on average, the more tions may be performed on the integrated system from a 

recent records are the records that will be manipulated more remote location using the communications processor 20. In 

frequently. this manner, the integrated system is remotely program- 

The data base processor 14 also communicates with a mable and configurable. The communications processor 20 

report writer 16 to allow for the compilation and output of 30 is constructed in such a manner to allow for the efficient 

report information in various formats such as data files, communication with conventional modem-based communi- 

printed reports, and report inquiries. cation or dedicated high speed data links. The communica- 

The security processor 12 provides both user-level and tions processor 20 acts as an interface between the integrated 

object-level security. An object for the integrated system system and whatever communication facilities are available 

may comprise, for example, a particular file, reports created 35 via network connections. The communications processor 20 

by the report writer 16, or a particular program or menu k independent of the communication facility such that the 

item. Under multi-processing platforms such as UNIX- operation of the integrated system is not changed or affected 

based platforms, the security processor 12 may comprise an depending on what sort of communication facilities are 

independent process such as a terminate and stay resident available to a particular implementation of the integrated 

(TSR) program which functions to monitor the processing 40 system. 

and accesses of all the remaining processes. Under single The execution control processor 10 is also coupled to a 
process platforms, such as MS DOS, the security processor help processor 22 which provides chapter-sensitive help to 
12 may be constructed within each object to monitor access a user of the integrated system. According to one embodi- 
to that object. Particular security routines relative to par- ment of the present invention, the help file is chapter- 
ticular objects will be discussed more fully herein. In 45 sensitive in that the integrated system provides the appro- 
general, however, the security processor 12 provides for priate chapter of a help file depending upon where the user 
multi-level user and object -based security for the integrated is during the navigation of the integrated system. Chapter- 
system. For example, the security processor 12 provides for sensitive help is a fast way of providing help that allows for 
supervisory and general user security access to various easy adaption of the help file to a particular implementation, 
objects. The security processor 12 interfaces directly with a 50 The help file is a text file which can be edited from within 
graphical user interface 18 to monitor attempted accesses to the execution control processor 10 to provide for specific 
various objects within the integrated system made by users help information for particular implementations. For 
of the graphical user interface 18. example, the help file can be edited to provide names and 
The graphical user interface 18 may provide, for example, telephone numbers of particular support personnel specific 
a mouse-driven or keyboard-driven user interface to allow 55 t0 an installation of the integrated system, 
for the efficient navigation of the various objects and capa- According to an alternate embodiment of the present 
bilities of the integrated system. The graphical user interface invention, help processor 22 provides fully context-sensitive 
18 begins with a main application menu which allows the help based upon the cursor position at the time the user 
user to select a variety of capabilities of the system. The requests help. According to this embodiment, the user is 
operation of the integrated system and the objects that are 60 provided with a portion of a help text file that is specifically 
constructed to perform the various functions of the inte- addressed to the task being attempted by the user at that 
grated system can be best understood by examining the particular time. Fully context-sensitive help is not as fast or 
menus and flow charts associated with the particular objects as easily adapted as chapter-sensitive help, but can provide 
which will be described in more complete detail in FIGS. 2 for more specific information available to the user without 
through 28 herein. In general, however, the graphical user 65 further navigation within the help processor 22. 
interface 18 interfaces with the security processor 12 in The operation of the integrated system is further enhanced 
order to present the user with the appropriate options for that through the use of grammar files 24 and parameter files 26 
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shown in FIG. 1. An important technical advantage of the Certain parameters within parameter files 26 can affect the 

integrated system of the present invention inheres in the fact operation of the graphical user interface 18. For example, a 

that the grammar files 24 allow for user-sensitive program- particular parameter might select a check format that 

mability of the graphical user interface 18. In operation, a requires a different set of data entry screens to be presented 

user identification is used by the integrated system to select 5 to the user. 

an appropriate grammar file from which to provide the data The execution control processor 10 is also coupled to a 

for the fields within the screens of the graphical user print processor 28 which serves as an interface between the 

interface 18. This data is taken on a field-by-field basis from execution control processor 10 and a printer 30. In general, 

one of the grammar files 24 applicable to the particular user thc ^ processor 28 operates to communicate data to be 

of the integrated system. Accordingly the fields of text that rinted b the rinter 3Q Tfae inter 3Q sefyes tQ ^ tfae 

are used by the graphical user interface 18 are not hard- finaQcial instru ^ ents such J orders an / official 

coded textual material, but are in fact variables that can be , , , , , , t , , ,f . , t , 

changed by manipulating the grammar files 24. In this seated and documented by the integrated system, 

manner, the graphical user interface 18 can be customized on ^ P nnte [ 3 ? also ^ chons c to P nnt vanous re P orts asso " 

a user-by-user basis. For example, a standard grammar file cialed wth the °P eratl <>D of the integrated system. The 

can be stored within grammar file 24 to provide for English 15 P nater 30 ma y com pnse a laser printer that is capable of 

textual material to appear within the screens of the graphical printing using a magnetic ink character recognition (MICR) 

user interface 18. In addition, a foreign language equivalent font - Tn e MICR font is used to place encoded characters on 

of the standard grammar file can also be stored in grammar eacn °f the financial instruments based on a standard as 

files 24 for use by users of the graphical user interface 18 prescribed by the American Banking Association that can be 

fluent in that foreign language. In this manner, an English- 20 read by magnetic character recognition systems used by the 

speaking user and a Spanish-speaking user can use the financial institution cashing the financial instrument. In 

identical functionality of the integrated system through addition to the ability to access a MICR font, the printer 30 

graphical user interfaces which are customized to their has a variety of other security features to enable the secure 

particular language preference. In addition, the execution operation of the integrated system. The printer 30 is capable 

control processor 10 provides for editing capability of the 1S 0 f bidirectional communication through the print processor 

grammar files to allow for particular installation of the 28 to the execution control processor 10. In this manner, the 

integrated system to customize the grammar files to their printer 30 can request and receive a password from the 

own needs. For example, a particular financial institution execution control processor 10 prior to accessing the MICR 

might not refer to their personnel as "tellers" but might font to create a financial instrument. This bidirectional 

/ prefer the term "customer service representatives". 30 communication further allows the printer to communicate 

Accordingly, the variable associated with the term "teller" error codes created during the printing process to the execu- 

\ within the grammar files 24 could be changed by a super- tion control processor 10 to allow the execution control 

visor at that installation to "customer service representa- processor 10 to establish which financial instruments have 

tlves ■ been created prior to the error condition and which have not 

The grammar files 24 are linked through the security 35 been created prior to the error condition. These error codes 

processor 12 to the profiles associated with particular users may comprise, for example, data indicating that the printer 

of the integrated system. In this manner, a user is shown the is jammed, that the toner is low or out, that the printer is out 

textual material within the graphical user interface 18 of paper or off-line. The information as to exactly what has 

according to his preferences and according to his security and has not been printed by the printer 30 is essential to 

level as monitored by the security processor 12. 40 proper accounting for the financial instrument. For example, 

The parameter files 26 provide for additional config- if a series of financial instruments such as money orders are 
urability for the integrated system. The parameter files 26 being printed and a printer jam occurs after two of them have 
include values for variables associated with the operation of printed, the execution control processor 10 must properly 
the integrated system that require more rigorous monitoring log the creation of two financial instruments and must 
than those associated with the variable textual material 45 attempt to recreate the third financial instrument. If the 
within the grammar files 24. For example, the parameter printer 30 were not able to communicate the error condition 
files 26 may store fee structures, security codes, user iden- back to the execution control processor 10, the execution 
tification codes, transaction dollar limits and printing param- control processor 10 might assume erroneously that every 
eters. These parameters are not fully variable in the sense item that was sent to print actually printed, 
that the values for the parameters must be within some 50 The ability of the printer 30 to access on a secure basis a 
defined range in order for the proper functioning of the MICR font allows for the creation of the financial instru- 
integrated system. The execution control processor 10 and ments to be accomplished within the printer 30 from blank 
the security processor 12 cooperate to allow the editing of stock. The blank stock has no intrinsic value and cannot be 
the parameters provided that the user attempting to do the used to fraudulently create financial instruments. As such, 
editing has sufficient security and supervisory authority. The 55 the blank stock need not be accounted for and secure storage 
security associated with the parameter files 26 may comprise of the blank stock is not necessary. As discussed previously, 
many levels. For example, a teller in a financial institution the use of the bidirectional communication and password- 
may not have access to any of the parameter files 26. A based security between the execution control processor 10 
supervisor at the financial institution may have access to and the printer 30 through the print processor 28 prevents 
some parameters, but might not have access to identification 60 fraudulent use of the printer 30 to create financial instru- 
numbers for the financial institution or for parameters which ments. If someone were to steal the printer 30, the MICR 
disable whole sections of the integrated system that are not font could not be accessed because the printer 30 must 
implemented at that particular financial institution. In receive the appropriate security signals from thc integrated 
addition, the financial institution supervisor may not have system prior to printing any financial instrument. According 
access to particular dollar limits on transactions that have 65 to one embodiment of the present invention, the printer 30 
been imposed on that financial institution by the operator of comprises a Hewlett-Packard Laser Jet 4 printer with the 
a super server or host accounting facility. MICR font contained on a separate SIMM card within the 



06/12/2003, EAST version: 1.03.0002 



5,7' 

7 

printer. The SIMM card also may comprise a secure numeric 
font that is used to print the amounts on the financial 
instruments. This numeric font includes characters that 
cannot be altered to fraudulently increase the amount of a 
financial instrument. 

The integrated system described with reference to FIG. 1 
may be constructed as a stand-alone unit with all compo- 
nents of the system residing, for example, in a personal 
computer coupled to the printer 30. In the alternative, the 
system of the present invention may be implemented in a 
network environment. In this environment, various proces- 
sors described may be physically located in dedicated serv- 
ers. For example, the graphical user interface 18 might be 
located in a user node while the execution control processor 
10, the grammar files 24, the parameter files 26 and the help 
processor 22 might be resident in a file server coupled to the 
user node through the network. Under this implementation, 
the print processor 28 and the communication processor 20 
may be located in dedicated servers as well. The system of 
the present invention is constructed as an object-oriented 
integrated system to allow for portability between a variety 
of both stand-alone and network-based platforms. 

The modular nature of the architecture of the system of 
the present invention allows it to be efficiently integrated 
into existing systems. For example, the operations of the 
system of the present invention used to create and manage 
various financial instruments can be accessed through other 
software user environments in place of graphical user inter- 
face 18. In this manner, the functional capabilities of the 
system of the present invention can be integrated into 
existing systems using existing user interfaces. Existing 
capabilities other than the user interface can also be used. 
For example, existing communications facilities can be 
accessed in place of communication processor 20 in order to 
efficiently integrate new functionality into existing systems. 
Existing communications facilities can be used to transmit 
consolidated data from a variety of sources to a host facility. 

FIGS. 2 through 28 illustrate the menu options available 
to a user of the integrated system as well as flow charts of 
the processing performed by the integrated system in 
response to the user's commands. FIG. 2 illustrates the 
sign-on security measures as well as the main application 
menu. Referring to FIG. 2, the application begins at step 32 
and proceeds to a decision point 34 where a parameter is 
tested in parameter files 26 to determine whether or not a 
supervisor security level sign -on procedure is enabled. If a 
supervisor sign-on is required, the method proceeds to step 
36 where a supervisor sign-on operation is performed. The 
security sign-on step 36 requires a supervisor to enter a 
recognized supervisor user identification and a password in 
order to begin the application for any users of the integrated 
system. The supervisor's sign -on process can also request 
supervisor verification of the business day for the applica- 
tion. Financial institutions usually perform transactions on a 
business day basis. After the supervisor has successfully 
signed on in step 36, the system of the present invention 
proceeds to step 38 where the teller sign -on and security 
operations are performed. The method can proceed directly 
from decision block 34 to teller sign-on step 38 if the 
parameter file 26 does not require a supervisor sign-on step. 
The teller sign-on step requires an input user identification 
to match an input password associated with that teller. After 
the security processor 12 has successfully checked the 
security for the particular teller signing on, the execution 
control processor 10 crosslinks the grammar file associated 
with the particular teller into the graphical user interface 18 
so that the particular teller is presented with screen field 
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definitions taken from his/her selected grammar file. 
According to one embodiment of the present invention, a 
"time out" security function exists, where after a certain 
period of time expires, as defined in the parameter file, the 

5 program automatically logs off and returns to the main teller 
sign-on screen. 

The integrated system then presents the main application 
menu 40 which is shown in detail in FIG. 2. The main 
application menu includes six sub-menus that are accessed 

10 as pull-down menus from the main application menu 40. The 
six sub-applications include the file sub-menu 42, the official 
check sub-menu 44, the money order sub -menu 46, the 
closing sub-menu 48, the administration sub-menu 50 and 
the help sub-menu 52. FIGS. 3 through 28 illustrate the 

15 sub -menu commands available to the user of the application 
and the flow chart representations of the steps performed by 
the integrated system in response to those commands. 

The official check sub -menu 44 allows a teller to process 
a financial instrument referred to as an official check. When 

20 the teller selects the official check sub-menu 44, the first 
option presented in the pull-down menu is the create check 
option. FIG. 3 is a flow-chart representation of the opera- 
tions performed by the integrated system to create an official 
check. The method illustrated in FIG. 3 begins at branch 

25 point A and proceeds to a decision block 54 where a 
determination is made by execution control processor 10 
whether security procedures are required prior to creating an 
official check. This decision is based on information stored 
in parameter files 26. If security information is required, the 

30 method proceeds to step 56 where the user attempting to 
create an official check is asked once again to sign on with 
their user identification and password to insure that the same 
person that signed onto the main application is trying to 
create an official check. Further, the security processor 12 

35 can once again check the user identification to make sure 
that the particular teller is authorized to create official 
checks. The method then proceeds from step 56 or directly 
from step 54 to step 58 where the first of the official check 
creations screens is presented to the user through the graphi- 

40 cal user interface 18. The official check requires, at a 
minimum, the name of the payee, the name of the remitter 
and the amount of the official check. The method proceeds 
from step 58 to a decision block 60 where a decision is made 
as to whether or not additional remitter information is 

45 necessary. If additional remitter information is necessary, the 
method proceeds to step 62 where the remitter information 
is gathered and input into the integrated system. An impor- 
tant technical advantage of the present invention inheres in 
the fact that the methods used to create financial instruments 

50 automatically prompt the user of the integrated system to 
acquire remitter information when certain predetermined 
dollar amounts are exceeded. Under the Bank Secrecy Act, 
financial institutions are required to ask for the remitter's 
name and other identification materials when a particular 

55 remitter attempts to get financial instruments in excess of a 
particular dollar amount in a particular amount of time. 
These guidelines can be configured into the integrated 
system of the present invention to prompt the teller to ask for 
identification and to input that identification material into the 

60 data base processor 14. Accordingly, the system of the 
present invention provides for an automated system to 
comply with the guidelines of the Bank Secrecy Act and thus 
eliminates human error on the part of the teller that might 
result in non-compliance with the Bank Secrecy Act. The 

65 checks performed in decision block 60 are comparisons to 
values within the parameter files 26. As such, as the guide- 
lines of the Bank Secrecy Act are amended or as other 
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financial institutions are required to obtain remitter 
information, the integrated system of the present invention 
can be reconfigured to comply with such changes. The 
graphical user interface 18 can provide specific screens to 
allow for the user to input the required remitter information 5 
so that the data can be captured and stored. 

The parameter files 26 supply default values which are 
used during the creation of financial instruments to provide 
for default values of various fields on the financial instru- 
ment. Accordingly, the screen that is presented to the user 10 
when the user is preparing a financial instrument already has 
values for many of the fields. If the user chooses to edit these 
fields, the default value is replaced with the value entered by 
the user. However, the default value remains to form a 
complete financial instrument if the user does not edit the 15 
default value. In this manner, a particular financial institu- 
tion can provide a set of defaults appropriate to that par- 
ticular institution and save a teller a great deal of time in 
preparing financial instruments. 

The method of the present invention proceeds from step 2 o 
62 or directly from decision block 60 to a decision block 64 
where a determination is made as to what form of official 
check is to be used by the system in this particular instance. 
The process described in FIG. 3 includes three different 
forms although other forms may be used by the present 2 s 
invention. The first form only includes the payee and the 
amount of the check and, as such, proceeds directly from 
decision block 64 to the collection block 66 with an extra 
copy of the check. Alternatively, the check can be of the free 
form variety as determined in decision block 64. The process 30 
would thus proceed from decision block 64 to block 68 
where any appropriate material to be printed on the memo 
voucher for the official check can be input. Finally, the 
method may proceed from decision block 64 to block 70 
where the top half of the memo voucher is completed by the 35 
teller. The method then proceeds to block 72 where the 
bottom half of the memo voucher associated with the official 
is completed. Finally, the method proceeds to step 74 where 
the free form area of the memo voucher associated with the 
official check is completed. 40 

The method proceeds from step 74 to decision block 64 or 
step 68 to the official check collection block 66. In step 66, 
the system of the present invention uses the fee schedules 
within parameter files 26 to assign a standard fee associated 
with each amount of the official check. This standard fee is 45 
presented to the teller to obtain collection from the remitter. 
The method then proceeds to step 76 where a determination 
is made by the system or by the teller as to whether or not 
the standard fees may be waived or adjusted. If the standard 
fees may not be waived or adjusted, the method proceeds 50 
directly to step 78 where the printing of the official check 
takes place. 

If at step 76 the waiver or adjustment of fees is allowed 
and requested, the method proceeds to a decision block 80 
where the parameter files 26 are accessed to determine 55 
whether or not security is required prior to the waiver or 
adjustment of fees. If security is required, the method 
proceeds to step 82 where the appropriate supervisory 
authority must be provided before any fees can be waived or 
adjusted. Supervisory authority may comprise, for example, 60 
a user identification and password associated with an autho- 
rized user. The method proceeds from step 82 or directly 
from step 80 if no security is required to step 84 where the 
teller is asked to give or select a reason why the fees are 
being adjusted or waived. According to one embodiment of 65 
the present invention, the teller is provided with a menu of 
appropriate reasons to adjust or waive fees such as preferred 
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customers or errors on the part of the financial institution. 
The teller then logs the reason for adjusting the fees using 
the menu or by inputting new reasons and inputs the amount 
of the adjustment. According to one embodiment of the 
present invention, the adjustment of fee reasons is linked 
into the security associated with the particular user. 
Accordingly, if the teller selects from a particular set of 
preauthorized reasons, no security is required. However, if 
the teller inputs a new reason or selects from a different set 
of reasons for waiver or adjustment of fees, then a user with 
supervisory authority must provide the appropriate authority 
to log the waiver adjustment of fees. 

According to one embodiment of the present invention, 
each particular implementation of the system of the present 
invention can include suggested adjustment amounts or 
percentages associated with the suggested reasons presented 
to the teller. For example, a preferred customer might be 
allowed a flat rate or percentage discount on fees. If the 
suggested amounts of discounts were altered by the teller, 
further authorization would be required. An important tech- 
nical advantage of the present invention inheres in the fact 
that the reasons for waiving and adjusting fees and the 
record of how much of the fee was waived or adjusted is 
recorded in the data base associated with data base processor 
14. Accordingly, the financial institution is provided with a 
log of exactly how much waiver and adjustment of fees is 
occurring on a teller-by-teller basis. The method proceeds 
from step 84 or directly from step 76 to step 78 where the 
official check is printed. 

As discussed previously, the communication between the 
execution control processor 10 and the printer 30 through 
print processor 28 is a secure communications path. Accord- 
ing to one embodiment of the present invention, the serial 
number of the printer is stored in the parameter files 26. This 
serial number is transmitted to the printer 30 before any 
printing takes place or alternatively, the printer 30 may 
transmit the serial number to the execution control unit 10. 
In either case, the serial number of the printer 30 is checked 
against the serial number stored in the parameter files 26 to 
verify that the correct printer is being used. The printer then 
responds over the bidirectional communications path with a 
request for the password associated with the printer. The 
integrated system of the present invention must respond to 
the printer 30 with the appropriate password before the 
MICR font stored in the SIMM board within the printer 30 
can be accessed. The data is then retrieved from the data 
within data base processor 14 and transmitted as a data 
stream to the printer 30 through the print processor 28. Also, 
as discussed previously, any error codes generated by the 
printer during the printing of financial instruments are 
transmitted back to the execution control processor 10 to 
allow for the accurate accounting of partially created finan- 
cial instruments or transactions. The MICR font may com- 
prise numeric characters that are difficult to alter and may 
further comprise the spelling for each number printed under 
each numeric character. 

The system of the present invention allows for the print- 
ing of captured material on financial instruments. For 
example, company logos and signatures can be captured and 
stored within the system. These logos and signatures can 
then be printed on an item when it is created. The system can 
be configured to selectively include a logo and to select from 
different signatures depending on, for example, the amount 
of the financial instrument. 

The serial numbers associated with particular financial 
instruments are generated at the time of printing and printed 
on the blank stock with the remainder of the information 
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printed on the check. Accordingly, there is no need to base and zeroed out to completely correct the accounts 
maintain stock with serial numbers already preprinted on the associated with the transaction. However, if the financial 
stock. The blank stock used by the system of the present instrument was issued on a prior business day, a corrective 
invention need not be stored in a secure environment transaction must be entered in the current business day in 
because it is worthless until a serial number, a MICR code, 5 order to bring all accounts into balance. It is not proper in 
and an amount are printed on the stock at the time of the normal operations of financial institutions to access a trans- 
creation of the financial instrument. In addition, logos, action from a prior business day and change the transaction 
signatures and other information such as "fingerprint" codes data. This is due to the fact that transactions are customarily 
can be printed on the financial instrument blank stock when recorded and financially balanced on a business day by 
the instrument is created. A "fingerprint" code comprises a 10 business day basis. Accordingly, a countering transaction 
character string printed with an extremely small font that must be entered in a later business day to adjust the accounts 
may include an issue date, an issue time, a teller into balance. 

identification, a printer identification, a software version Referring to FIG. 4, the method proceeds to a decision 
identification, an item serial number and an item amount. block 94 where a determination is made as to whether or not 
According to one embodiment of the present invention, the 15 a stop payment is required and if a stop payment is required, 
serial numbers associated with particular financial instru- whether or not the particular implementation of the system 
ments can be self -generating in the sense that the financial enjoys the ability to do automatic stop payments using the 
institution identification number and a chronological iden- communications processor 20 and network communications 
tification of the particular financial instrument from that facilities as specified in parameter files 26. If no stop 
financial institution can be made a part of the serial number 2 o payment is required, the method proceeds directly to step 96 
for a particular financial instrument. In this manner, pro- where the transaction is either voided from the current 
cessing of the financial instruments upon cashing of the business day or a countering transaction is entered in the 
financial instruments can be greatly simplified in that the current business day. If the system enjoys the capability to 
serial number of the proffered financial instrument will perform automated stop payments, the method proceeds to 
identify the institution issuing the financial instrument. 2 s ste P 98 where a host stop pay request is performed by 
Whatever method is used to create or assign serial numbers, establishing contact with the host through communications 
the serial numbers are not assigned to the financial instru- processor 20 and the network connections discussed previ- 
ment and the data base associated with data base processor ously. In this manner, the host will log the stop pay request 
14 is not updated until printing of the financial instrument and prevent cashing of the check when the check is pre- 
actually occurs. The contemporaneous creation of the fin an- 30 sented to any financial institution associated with the host 
cial instrument and the creation of the record within the data system. If at decision block 94 the automated stop payment 
base prevents erroneous records from being created and operation is not available at the particular time or is not 
changed within the data base. available to that system, the method of the present invention 
FIG. 4 illustrates the method used by the system of the proceeds to step 100 where the teller is prompted to perform 
present invention when the user of the system selects the 35 a manual stop payment request by manually calling person- 
void or stop check selection from the official check sub- nel associated with the host computer to obtain authorization 
menu 44. The method proceeds from branch point B to a and log the stop payment. After the stop payment authori- 
decision block 86 where a decision is made based on a zation code is received back in the manual transaction, the 
parameter value within parameter files 26 as to whether or authorization code is entered into the system and the method 
not security is required before a void or stop check function 40 proceeds to step 96 where the stop payment action is logged 
is performed. If security is required, the method proceeds to and the voiding transaction is recorded, 
step 88 where a variety of security methods may be imple- An important technical advantage of the present invention 
mented. For example, the teller may be required to reenter inheres in the fact that all communications with the host 
his/her user identification and his password to be sure the system through the communication processor 20 also 
teller who logged on to the terminal is requesting the void or 45 involve security procedures. For example, a particular finan- 
stop check operation. Similarly, supervisory authority may cial branch contacting the host system through the commu- 
be required to do a void or stop check operation. As such, a nications processor 20 and network connections can only 
supervisor user identification and password maybe required access information relative to that branch. For example, in 
in step 88. The method proceeds from step 88 or directly the process described previously, if a branch were to attempt 
from step 86 if no security is required to step 90 where the 50 to do a stop payment on a check that was not issued by that 
void or stop selection screen is presented to the user. The financial institution, the host would transmit information to 
user inputs. three basic pieces of information to the system. the system through the communications processor 20 which 
The user inputs a check number, a check amount, and an would disallow the transaction. This type of security is used 
indication as to whether or not the party requesting the void whenever a particular system at a financial institution com- 
or stop check has the check in hand. If the check to be voided 55 municates with the host system. For example, as will be 
is in hand, the teller can retrieve the check and a stop described herein, financial institutions will sometimes make 
payment is not required. If the check is not in hand, a stop inquiries about transactions or financial instruments to the 
payment is required. The method proceeds from step 90 to host system. The host computer utilizes security routines to 
step 92 where the information input by the teller is displayed prevent a party from calling in and acquiring about any 
for verification. The teller can cancel the operation. The data 60 information on a financial instrument not issued by that 
base is accessed prior to step 92 to match the check number financial institution. 

with the appropriate check amount. FIGS. 5, 6, 7 and 8 relate to the operations performed 

The void or stop check operation is different depending under the official check sub-menu 44 and the inquiry sub- 

upon whether or not the financial instrument to be voided menu within the official check sub-menu 44. Referring to 

was issued on the same business day or a previous business 65 FIG. 5, the view a check option causes the application to 

day. If the financial instrument was issued on the same branch from branch point C to a step 102 where an infor- 

business day, the transaction can be retrieved from the data mation gathering screen is presented to the user through the 
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graphical user interface 18. The user inputs the check serial selected, the method proceeds to step 114 where the user is 

number. The method then proceeds to step 104 where the presented with an inquiry screen and inputs the item number 

execution control processor 10 retrieves the detail data from which may comprise, for example, the check serial number 

the data base associated with data base processor 14 and for an official check. The system of the present invention 

displays the check detail through the graphical user interface 5 tnen uses this serial number to access the data files of the 

18, host computer through the communications processor 20 

The inquiry functions do not require communication and network connections as described m step U 6 The host 

outside of the integrated system. The inquiry functions are computer returns all information associated with the par- 

merely accessing information stored in the data base asso- ticu ^ ar ltem and m f te P U8 > and me formation is displayed 

ciated with data base processor 14. The user has the capa- w t0 the Typically, the user is performing the paid status 

bility to configure the amount of data that is maintained by t0 determine if a particular financial instrument has 

the data base processor 14 using the parameter files 26. For been P aid or 15 authonzed for payment. If a financial 

example, a user may choose to maintain a single business ™trument has been paid, a stop check or void cannot be 

day's, a single business week's, or a single business month's P erfo nned on that particular financial instrument. Typically, 

worth of data even after such data is uploaded to a host « a teller ^ P erform a status inquiry function before 

system. This data is maintained largely for the purposes of atte *pting the void or stop check function described with 

making inquiries such as those described with reference to reference to FIG. 4 previously. 

the inquiry sub-menu under the official check sub-menu 44. FIG - 10 illustrates the operations performed by the system 

The view a check process described with reference to FIG. of the P re s ei it invention to perform a check copy request 

5 previously will often be used by a teller prior to entering 20 operation under the issued check request sub-menu of the 

the void or stop check process described with reference to official check sub-menu 44. Once the check copy request 

FIG. 4 to insure that the check is a check that is accessible operation is selected, the method proceeds to a branch point 

by the particular user. 1-^ where a determination is made using the parameter files 

nn c -ii * * *u _f 1 1 ,i . 26 as to whether or not security is required to perform a 

Flu. 6 illustrates the operations performed by the system , , T , * . \ r 

-f ™- #u * ii u * a r •« a u u 25 check copy request. In general, the check copy request is an 

in performing the teller business day activity and the branch / • , • • * 

. . j •* c j *i_ ■ • u automated method that a financial institution can use to log 

business day activity functions under the inquiry sub-menu. - - _ . f . , fo 

r> *u t *u a* * mi u *u a request for a copy of a financial instrument that has already 

Both of these processes proceed to a step 106 where the i ,■..«..,, . . . 

! . , . j * , i l ii_ tt cleared and is being held by a supervisory accounting 

particular inquiry business day is selected by the user. Upon J , • , , ^ . , 

. . * u • ♦ ■ ■ *u / . *u service operating the host computer to which the financial 

receiving the appropriate inquiry, the system presents the • ♦ a a a- u j- * c 

J? M me „,-fiT*i,* ♦ • i a * *i f ii * ♦* 30 mstitution is connected. According to one embodiment of 

user in step 108 with the sequential detail of all transactions . . . , . 6 

entered by the teller or by the branch depending upon the the , P rese °' .^ntion cleared items are captured optically 

selection made in step 106. The user is presented With an a ° d ™"" alned * • host-based imaging system. When a 

option in step 108 to print a report which includes the detail t T^T, " "'T?' ! he ° pl,Ca ^ ^ * retneve k d 

~r^„t^ ;n ct on me from the host and transmitted via facsimile or modem to the 

presented in step lUo. , , , , 

. . 35 local system where the cleared item is printed using printer 

Similarly, FIG. 7 illustrates the operation of the system of 30 ^ step performed in step 120 shown in FIG. 

the present invention in- performing the teller current shift 10 may be necessary ^c^^ lhe check copy request 0 era . 

activity operation and the branch current shift activity opera- tion k usually assochtcd with a fee t0 the financial institu . 

tion under the inquiry sub-menu. When either of these items tion M suchj only certain authorized personnel may be 

are selected, the method proceeds to step 110 where the 4Q allowed to perform the check cop r t function . 0nce 

details of each transaction recorded by the teller during the tne security checks have been performed in sl 120 0 r 

current shift or the branch during the current shift are directly from step U8> the method proceeds t0 step 122 

presented through the graphical user interface 18. Ilie user where the {tem number is retfieved from the user The 

is presented with the option of once again printing a report melhod then proceeds t0 step 124 where a connection is 

of the detail presented. 45 made mrough the communications processor 20 and the 

FIG. 8 illustrates the operations performed by the system network connections described previously to the host com- 

of the present invention to present historical branch sum- pu ter. The host computer will then log a request for a copy 

mary data. When this function is selected under the inquiry of the particular item and the staff associated with the host 

sub-menu, the method proceeds to step 112 where the computer will make the physical copy and mail it to the 

historical branch summary totals by business day are pre- 50 financial institution. The host computer returns an acknowl- 

sented. Once again, the user is given the option of printing edgment of the logged check copy request to the system of 

a historical summary report. The user identification request- the present invention through the communications processor 

ing the particular activities may be checked by the security 20. This response is displayed to the user in step 126. 

processor 12 for some of the functions described. For FIG. 11 illustrates the operations performed by the system 

example, the branch business day activity and the branch 55 0 f the present invention to perform the pay authorization 

current shift activity may require supervisory identification reqU est function under the issued check request section of 

before access is allowed to such data. In order to perform the the official check sub-menu 44. The pay authorization 

security checks, the security processor 12 accesses the request is essentia Uy the opposite of a stop payment request, 

profile of the user signed on at that particular time to when a financial institution is presented with a financial 

determine whether that user has access to the various 60 instrument to be cashed, the financial institution can contact 

functions requested. If the user does not have access to that tne nost computer to receive an authorization for cashing an 

function, a security violation message is displayed for the i tem . The method begins when the pay authorization request 

user and the requested functions are not performed. ^ selected and proceeds to a decision block 128 where a 

FIG. 9 illustrates the operations performed by the system determination is made by accessing the parameter files 26 as 

of the present invention in order to do a paid status inquiry 65 to whether or not a security check is required prior to making 

operation under the issued check request section of the a pay authorization request. If a security check is required, 

official check sub-menu 44. Once the paid status inquiry is the security check is performed in step 130 using the 
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methods described previously. The method proceeds from 
step 130 or directly from step 128 to step 132 where the 
identification information from the financial instrument is 
input into the system of the present invention. This can 
include the serial number of an official check and the amount 5 
of the check or other information specifically identifying the 
particular financial instrument. Once the information is 
received from the user, the system of the present invention 
establishes contact in step 134 with the host system through 
the communications processor 20 and the network connec- 
tions as described previously in step 134. The host system 
then checks to see if any stop payments have been issued for 
that financial instrument. If no stop payments are issued and 
no other irregularities exist related to the financial 
instrument, the host system will return an authorization to 
the system of the present invention which is displayed for 15 
the user in step 136. 

FIG. 12 illustrates the operations performed by the system 
of the present invention when the report writer facility is 
selected under the official check sub-menu 44 or the money 
order sub-menu 46. The operation continues from a branch 20 
point W to a report selection step 140 where the user is 
presented through the graphical user interface 18 with a 
selection screen. The user is presented with a list of format- 
ted reports that may be compiled from the information 
stored in the data base associated with data base processor 25 
14. The user has the option of running any of the formatted 
reports in the background or to view, print or export reports 
that have already been run. If the user selects to view a 
report, the method proceeds to step 142 where the detail data 
from the report is presented to the user through the graphical 30 
user interface 18. If the user elects to print a report that has 
already been run, the method proceeds to step 144 where the 
report data is formatted and output to the printer 30 through 
print processor 28. The user also has the option to proceed 
from step 140 to step 146 where the print data is exported as 35 
a data file. In step 146, the user is asked in what format the 
data should be placed and what file name the data should be 
assigned. The data may be formatted, for example, as an 
ASCII delimited or ASCII fixed data file. In step 140, the 
user also has the option to define new customized reports or 40 
modify existing report definitions. If the user selects this 
option, the user proceeds to step 148 which asks the user to 
input the header for the report. The header for the report is 
a general description of the data to be presented in the report. 
The method then proceeds to step 150 where all the fields 45 
that are available to the user are presented. The user then 
selects which fields are to be included in the report. The 
method then proceeds to step 152 where the user specifies 
the sort order, selection criteria, and other field definition 
selections for the particular report being configured. For 50 
example, the user can elect to sort on a particular field and 
select only data records having a field value within particular 
range of values. 

Using the reporting capabilities and fee management 
systems of the present invention, financial institutions can 55 
compile fee management reports that present detailed infor- 
mation as to the amounts of fees collected by the institution 
and particular personnel and, specifically, the amount of 
adjustments to fees and associated reasons for adjustments 
made by various personnel. In addition, the reporting capa- 60 
bility of the present invention can be used to automatically 
create reports comprised of the information required of the 
Bank Secrecy Act. The system of the present invention, as 
discussed previously, can automatically prompt the teller to 
gather the remitter information required to comply with the 65 
Bank Secrecy Act and automatically generate a report of 
such information contemporaneously with the transaction. 



FIGS. 13, 14 and 15 relate to the transmit function under 
the official check sub-menu 44 and the money order sub- 
menu 46. The transmit functions are largely a back-up to the 
automated transmissions used by the system of the present 
invention to contact the host system through the communi- 
cation processor 20 and the network connections as 
described previously. The transmit functions described with 
reference to FIGS. 13, 14 and 15 are manual transmissions 
which are used if the automatic transmission of data to the 
host does not occur for some reason. For example, FIG. 13 
illustrates the transmission of all transactions which are 
closed but not yet transmitted. The method proceeds from 
branch point X to a step 154 where the system of the present 
invention polls the data base associated with data base 
processor 14 and selects all transactions which have been 
closed but which have not yet been successfully transmitted 
to the host system through the communications processor 
20. The method then proceeds from step 154 to step 156 
where a communications path is established through the 
communications processor 20 and the network connections 
as described previously to the host system. Once a commu- 
nications path has been established, all the selected trans- 
actions are transmitted to the host system and the transac- 
tions are flagged within the data base associated with data 
base processor 14 as being successfully transmitted. 

FIG. 14 illustrates a similar operation as that described 
with reference FIG. 13 for a selected closed business day. 
The method proceeds from branch point Y to a step 158 
where the user is asked to specify a particular closed 
business day to transmit. The method then proceeds to step 
160 where the records associated with that business day are 
selected. This function can be used for original transmission 
of data or for the transmission of data that had already been 
transmitted previously. The method then proceeds to step 
162 where the selected records are transmitted to the host 
using the method described previously with reference to 
FIG. 13. 

FIG. 15 represents the process used by the system of the 
present invention to make a test transmission to the host 
system. The method proceeds from branch point Z to a step 
164 where the user confirms that the test transmission is to 
take place. The method then proceeds to step 166 where a 
communications path is established with the host computer 
in order to verify that the communications processor 20, the 
network connections, and the communications facilities 
associated with the host computer are all functioning prop- 
erly. 

It should be understood that under ordinary 
circumstances, the system of the present invention will 
automatically transmit all closed transactions to the host 
computer on a periodic basis. For example, the configuration 
files stored within the parameter files 26 can establish a time 
during off hours where an automatic connection with the 
host system is made via the communication processor 20 
and the network connections. Once this connection is made, 
the system of the present invention will automatically 
upload all of the closed transactions to the host system that 
have not yet been successfully transmitted. 

Referring again to FIG. 2, the money order sub-menu 
provides identical options as the official check sub- menu 44 
for the creation and processing of money orders. The screens 
presented to the user through the graphical user interface 18 
and the operations performed by the execution control 
processor 10 are substantially identical to those described 
previously with reference to the official check sub-menu 44 
and the operations accessible thereunder. The primary sub- 
stantive difference between the money order financial instru- 
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ment and the official check financial instrument is that a at branch point b and proceeds to a step 174 where the teller 

money order traditionally has a much smaller maximum confirms a shift close. A number of shifts can occur during 

value and, as such, the system of the present invention the business day. The teller shift close operation allows for 

allows for the automatic or manual creation of multiple a teller to prepare periodic reports during a business day 

money orders in a single transaction. For example, if the 5 without affecting the business day to which the transactions 

maximum dollar amount for a money order was $500.00 and before and after the report are logged. The method proceeds 

a customer requested money orders in the amount of from step 174 to step 176 where a teller shift close report is 

$700.00, the system of the present invention would auto- printed with the transactions for that teller shift, 

matically create a $500.00 money order and a $200.00 FIG. 18 illustrates the operations performed by the system 

money order to complete a single transaction. In addition, 10 of the present invention to perform the branch business day 

the system of the present invention allows for a teller to close operation. The method of the present invention begins 

create many different money orders to different payees using at branch point c and proceeds to step 178 where someone 

the same screen before printing any of the money orders. with supervisory authority and security clearance confirms 

Each of the money orders created can be edited before the the branch business day close operation. The method then 

entire batch of money orders is sent to print through the print 1S proceeds to step 180 where a branch business day close 

processor 28 to the printer 30. report is prepared. The branch business day close operation 

The creation of multiple financial instruments at one time & similar to the teller business day close operation except it 

requires that the system of the present invention monitor closes all teller accounts simultaneously for the branch, 

closely the printing of the multiple financial instruments in Branch-close operations and teller-close operations can be 

the event of printer malfunction. For example, if four money 20 mixed. For example, a branch-close operation can be used to 

orders are sequentially processed from a single transaction c ^ ose au " tne remaining open tellers, and to produce a close 

and the printer runs out of paper or is jammed in the middle report for the entire branch. 

of printing the four money orders, the system of the present Similarly, FIG. 19 represents the branch shift close opera- 
invention must receive exact information as to which, if any, tion. The method of the present invention proceeds from 
of the money orders were printed prior to the printer running 2 s branch point d to step 182 where someone with supervisory 
out of paper or entering the jammed condition. As discussed authority and security clearance confirms the branch shift 
previously, the system of the present invention enjoys bidi- close operation. The method then proceeds to step 184 
rectional communication with the printer 30 through the where a branch shift close report is printed. The branch shift 
print processor 28. As such the specific error messages close operation is similar to the teller shift close operation 
retrieved from the printer 30 can be used to automatically 30 except that the branch shift close operation simultaneously 
account for which financial instruments have been printed prepares an interim report for all tellers within the branch, 
and which must be retried. Accordingly, if multiple money According to one embodiment of the present invention, 
orders are being printed and an error condition occurs during the security processor 12 requires security checks during the 
the printing, the money orders that have been printed will be closing operations. For example, as described previously, 
logged as completed transactions and the system of the 35 the branch closing operation illustrated with reference to 
present invention will automatically prompt the user with FIGS. 18 and 19 may require supervisory authority prior to 
the error condition associated with a particular incident and performing these operations. Further, supervisory authority 
will ask the user if they want to retry printing the remaining may be required in specifying the next business day for a 
money orders. teller or a branch in order to prevent errors in establishing 

The remaining functionality shown in FIG. 2 under 40 the next business day applicable to the financial institution, 

money order sub-menu 46 is performed identically to those An important technical advantage of the present invention 

described with reference to the functionality described under inheres in its flexibility in separating business days and 

the official check sub-menu 44. actual days during the preparation of financial instruments. 

FIGS. 16 through 19 involve the operations performed by For example, the ability to selectively close particular tell- 

the system of the present invention under the closing sub- 45 ere' business days without affecting the operation of the 

menu 48. In general, the closing operation can be performed preparation of financial instruments allows the system of the 

by the system of the present invention in two ways. The present invention to efficiently distribute financial instru- 

system of the present invention utilizes an automatic close ments that are dated with the actual date regardless of the 

operation that is performed periodically to insure that a business day to which those financial instruments are attrib- 

financial institution does not skip a business day. However, 50 uted. Further, the ability to close particular tellers or to close 

the typical closing operation will be performed in response an entire branch allows for flexibility in the operation of a 

to an operation specified using the graphical user interface particular financial institution or retail establishment. In 

18 under the closing sub-menu 48. FIG. 16 represents the large financial institutions, the closing operation can be very 

operations performed for a teller business day close opera- complex in that it requires supervision on a teller-by-teller 

tion. The method of the present invention begins at branch 55 basis. The flexibility of the software system of the present 

point a and proceeds to a step 170 where the teller confirms invention allows for the supervision of closings to occur 

the closing of the current business day and confirms the date without affecting the operation and distribution of financial 

of the next business day as predetermined. All transactions instruments from remaining tellers in the branch, 

for the teller's closed business day are then printed in a close FIG. 20 represents the operations performed by the sys- 

report at step 172. When the first teller closes for a given 60 tem of the present invention when the back-up utility is 

business day, a supervisor approval is required to establish invoked under the file sub -menu 42. When the back-up 

the new business day; subsequent teller and business day utility is invoked, the method proceeds from branch point e 

closes for the same day may not require confirmation of the to step 186 where the conventional DOS-based back-up 

new business day. All transactions entered by that teller after utilities are invoked to create conventional data back-up files 

the close operation will then be entered on the next business 65 of all updatable files at step 188. These files may comprise, 

day entered by the teller. FIG. 17 illustrates the teller shift for example, the transaction files, grammar files, parameter 

close operation. The method of the present invention begins files, and help files. 
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Similarly, FIG. 21 represents the operations performed by The money order fee table is virtually identical to the official 

the system of the present invention when the restore opera- check fee table and is adjusted at step 200 by a user with 

tion is chosen from the file sub-menu 42. The method of the similar supervisory authority. 

present invention follows from branch point f to step 190 Although the present invention has been described with 

where the conventional DOS restore utilities are invoked. 5 fee tables and fee management functions associated with the 

The method follows the DOS restore operations to retrieve creation of financial instruments, it should be understood 

data from the DOS back-up files and to create the restored that similar functionality may be associated with other 

files at step 192. chargeable activities. For example, similar fee management 

Submenu 42 also includes the "logoff* and "exit" func- routines can be used for fees associated with stop payment 

tions. When invoked, the logoff function returns the teller to 1Q requests and check copy requests. 

the teller sign-on step 38 described previously. The exit fig. 25 illustrates the operations used by a user of the 

function terminates the application. present invention to edit a particular grammar file stored in 

FIG. 22 illustrates the operations performed by the system grammar files 24. Once the grammar file operation is 

of the present invention when the help sub-menu 52 is invoked under the administration sub-menu 50, the method 

invoked by the user. The method proceeds from branch point 15 proceeds from branch point j to a step 202 where grammar 

g to a step 194 where the table of contents for the help file file items are listed and selected to be edited. The method 

is displayed to the user. The user can then navigate through then proceeds to a step 204 where the selected item in the 

the table of contents to a particular chapter and the method grammar file is displayed for the user and the user can 

will proceed to step 196 where the detailed text for that change the textual material displayed for the item within the 

particular chapter is displayed. The user has the option with 20 grammar file. As discussed previously, the grammar file 

a displayed chapter to print the detailed text at step 196. As includes variable identifications for the various fields within 

described previously, the help utility may be invoked by a the screens of the graphical user interface 18. The system of 

user during operations outside of the context of the main the present invention can be configured and customized for 

application menu 40. In these contexts, the help is context- a particular user's needs by changing the contents of a 

sensitive at the chapter level. In other words, a user that is 25 particular grammar file. The grammar file to be used with a 

practicing a particular operation performed by the system of particular user is cross-linked with the user's identification 

the present invention will be directed to the chapter associ- so that a particular grammar file and the graphical user 

ated with that operation. FIG. 22 illustrates the invocation of interface 18 are cross-linked at the time the user logs on. In 

the help utility from the main application menu where the this manner, the system of the present invention can be 

table of contents is first presented to the user in step 194. 30 customized to a particular user's needs without necessity of 

Also, similarly, as was described with reference to grammar hard-coding the various screens within the graphical user 

files 24, the help file presented to the user may be cross- interface 18. 

linked with the user identification. Accordingly, user's help Similarly, FIG. 26 represents the steps used by the system 

is configurable to the particular user's need. This may be of the present invention to alter the system parameters stored 

used to provide foreign language help to user's fluent in that 35 w i t hin parameter files 26. Once the system parameters 

foreign language. In addition, the particular help file may be operation is selected under the administration sub-menu 50, 

customized to fit a particular installation. For example, a the method proceeds from branch point k to a step 206 where 

particular teller installation might be directed using the help syste m parameter file items are listed and selected to be 

file to contact a direct supervisor in certain circumstances. edited. The method then proceeds to step 208 where the 

Neighboring tellers might be directed to contact different 40 selected system parameter within the parameter file is dis- 

supervisors under the same circumstances. played for tne ^ and may be cdited by tne ^ ^ 

FIGS. 23 through 28 illustrate the operations performed security processor 12 closely monitors the editing process to 

by the system of the present invention under the adminis- insure that the values input by the user fall within any 

tration sub-menu 50. In general, the administration sub- necessary ranges for the system parameters. For example, a 

menu 50 will be closely guarded by the security processor 12 45 system parameter might be associated with the time in which 

due to the nature of the operations performed therein. In the automated upload process is performed on a daily basis, 

general, the administration sub-menu 50 deals with alter- The security processor 12 will insure that the value input by 

ations to parametric values that are used during the operation the user with the appropriate security is a valid time. Further, 

of the system of the present invention. As such, supervisory as discussed previously, the system parameter values may be 

authority is usually required to adjust any of the values. 50 subdivided into those accessible to day-to-day users, the 

Further, many of the values changed through the adminis- system administrator and persons servicing the software. A 

tration sub-menu 50 must be within ranges or be values of day-to-day user may have particular system parameters 

a particular nature such as numeric values in order for the available to him/her such as those associated with display 

system of the present invention to operate properly. As such, colors and other hardware configuration parameters. A sys- 

the operations performed under the administration sub-menu 55 tern administrator might be able to change the time for the 

50 in many circumstances contain field-by-field checks to automated caller proceeding or other global parameters 

make sure that the values entered by the person adjusting the associated with the operation of the financial institution site 

parametric values have entered appropriate values. and the persons servicing the software might be the only 

FIG. 23 illustrates the method used by the present inven- users allowed to change the serial number associated with 

tion to adjust the official check fee table. The official check 60 the financial institution or the telephone number to be called 

fee table is stored within parameter files 26 and is accessed for the automated call-up. The security processor 12 moni- 

in step 198 by a user with suitable supervisory authority. The tors the access requested and will allow the parameters to 

official check fee table is a table of dollar amount ranges and only be edited by persons having the required security level, 

a fee associated with that range. Both the ranges and the fee According to one embodiment of the present invention, 

for that range can be adjusted by the user. 6 5 the parameters stored in parameter files 26 may be accessed 

FIG. 24 illustrates the operation performed by the system and edited remotely through the network connections and 

of the present invention to adjust the money order fee table. communications processor 20. The access to the parameter 
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files 26 from a remote host is also managed by security 
processor 12. In this manner, the system of the present 
invention can be remotely maintained and configured using 
a remote host system. 

FIGS. 27 and 28 illustrate the operations performed under 5 
the security sub-heading under the administration sub-menu 
50. In general, the security operations are only accessible to 
a system administrator in that they generally deal with the 
ability of particular users to access various capabilities of the 
system. The security user definition and object maintenance 10 
operations provide information to the security processor 12 
as to what particular objects are available to what particular 
users. 

FIG. 27 illustrates the operations performed by the system 
of the present invention to define new user profiles and to 15 
edit existing user profiles. The method proceeds from branch 
point 1 to a step 210 where a particular user profile is selected 
from a list of existing users. The user also has the option to 
add a new user. If the user makes such a selection, the 
method proceeds to step 212 where the new user identifi- 20 
cation is received from the user and the user may copy an 
existing user profile for the new user. The method proceeds 
directly from step 210 or from 212 to step 214 where the user 
profile is defined and a password for the new user is 
requested and confirmed. The method then proceeds to step 25 
216 where the objects are listed for a particular user. The 
method then proceeds to step 218 where the tables that store 
the authorization for each object for a particular user is 
updated. A user profile comprises information identifying 
the user; his password; his authority designation of teller, 30 
supervisor, branch manager, or administrator; a help file 
designation; a grammar file designation; specific user 
parameters; and object authority security. The levels of 
object authority comprise no authority, read, write authority, 
change authority, delete authority, and existence authority. In 35 
general, the security associated with security processor 12 of 
the present invention is a hierarchical object-oriented secu- 
rity. The security processor 12 keeps track of a list of users 
and a list of objects which may comprise screens, programs, 
files, reports or particular fields within screens. The security 40 
processor 12 monitors the requested access of a particular 
user using the table of objects which are authorized to be 
accessed by that user. The user definition operation illus- 
trated with reference to FIG. 27 allows an administrator of 
a system to preclude a whole program and all the objects 45 
associated with that program from access by a particular 
user. In addition, the user can access the security of particu- 
lar objects in a hierarchical fashion and preclude particular 
screens or particular fields within screens from access for 
users. 50 

FIG. 28 represents the object maintenance operation per- 
formed under the administration sub-menu 50. The method 
proceeds from branch point m to a step 220 where all of the 
objects are listed and the user is presented with several 
options. The system administrator can proceed to step 222 55 
where particular users can be authorized access to a par- 
ticular object. The method then proceeds to step 224 where 
the tables described previously are updated with the new 
user authorization information. From step 220, the system 
administrator can also add a new object to the object list in 60 
step 226. If a new object is added, the method proceeds to 
step 228 where the new object is described. The method can 
also proceed directly from step 222 to step 228 if an existing 
object description must be edited. One type of object that is 
added to the object list is new reports formatted using the 65 
report writer capability described previously. The report 
writer program automatically adds any newly formatted 



reports to the object list. The system administrator can then 
authorize new users to access that report in step 222 and step 
224 described previously. 

The data processing system described herein integrates a 
sophisticated graphical user interface 18 with an object level 
security processor 12. In addition, sophisticated bidirec- 
tional communication with a printer 30 is utilized to provide 
for the efficient and secure printing of financial instruments. 
The operation and maintenance of the integrated system is 
enhanced through the use of grammar files and parametric- 
based files to allow for easy configuration and customization 
of the integrated system. 

Although the present invention has been described in 
detail, it should be understood that various changes, alter- 
ations and substitutions can be made to the description of the 
system described herein without departing from the spirit 
and scope of the invention which is solely defined by the 
appended claims. 

What is claimed is: 

1. A data processing system operable to process financial 
instruments, comprising: 

a graphical user interface operable to present a plurality of 
options to a user of the system; 

a data base processor operable to manage a data base of 
information associated with financial instruments pro- 
cessed by the system; 

a printer operable to print financial instruments responsive 
to data received from the data base processor, said 
printer using a magnetic ink character recognition font 
for selected portions of the financial instruments, and 
further operable to transmit error codes specifying error 
conditions encountered during processing of financial 
instruments; and 

a security processor operable to restrict access to selected 
functions of the system, the security processor being 
operable to confirm an identity of a user of the system 
prior to allowing access to the printer for printing the 
financial instruments, the security processor being fur- 
ther operable to compare a unique identifier associated 
with a particular printer, to a stored identifier to confirm 
the identity of the particular printer and operable to 
automatically transmit, in response to confirming the 
identity of the particular printer, a password associated 
with the particular printer to the printer to gain access 
to the printer to print the financial instruments after the 
password is confirmed. 

2. The data processing system of claim 1, further com- 
prising: 

a grammar file storage system operable to store at least 
one grammar file having a plurality of field definitions, 
the system being operable to use the field definitions 
within a selected grammar file as textual material for 
screens presented to the user by the graphical user 
interface. 

3. The data processing system of claim 2, further com- 
prising: 

a first grammar file comprising first field definitions with 
English language textual material to be used by the 
graphical user interface; and 

a second grammar file comprising field definitions with 
foreign language equivalents of the first field 
definitions, the system being operable to select from the 
first and second grammar files for use in the graphical 
user interface in response to a user identification input 
by a user of the system. 

4. The data processing system of claim 1, further com- 
prising: 
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a parameter storage system operable to store parameter 
values used by the system during the processing of the 
financial instruments. 

5. The data processing system of claim 1, further com- 
prising: 

a help processor operable to present to the user textual 
material providing guidance in the operation of the 
system, the help processor being operable to select and 
access a particular help file from a plurality of help files 
in response to a user identification code associated with 
a particular user of the system. 

6. The data processing system of claim 1, further com- 
prising: 

a communications processor operable to create and man- 
age a communications path between the system and an 
external host computer system, the communications 
processor being operable to transmit data from the data 
base to the host computer system and to receive infor- 
mation transmitted from the host computer system. 

7. The data processing system of claim 1, wherein the 
printer is operable to use a magnetic ink character recogni- 
tion font to print selected characters on the financial 
instruments, and wherein the printer must receive the pass- 
word associated with the particular printer prior to accessing 
the magnetic ink character recognition font. 

8. The data processing system of claim 1, further com- 
prising: 

a report writer operable to retrieve information from the 
data base and format the information into reports, the 
report writer being further operable to output the for- 
matted reports to the printer. 

9. The data processing system of claim 1, further com- 
prising a fee calculation system operable to calculate fees 
associated with the financial instruments processed by the 
system, the security processor being operable to monitor the 
processing of fees such that authorization and documenta- 
tion is required before the calculated fees can be waived or 
adjusted. 

10. The data processing system of claim 1, wherein the 
printer is further operable to request the password. 

11. A data processing system for processing data using a 
personal computer, comprising: 

an execution control processor comprising a data base 
processor operable to manage a data base of 
information, and a security processor operable to 
receive user identifications from users of the system 
and to control access of users to selected functions of 
the system; 

a laser printer bidirectionally coupled to the execution 
control processor, said laser printer including a secure 
font that can be accessed to print documents only upon 
receiving and confirming a password associated with a 
particular printer, said password being automatically 
transmitted from the execution control processor in 
response to confirmation of the identity of the particular 
printer using a unique identifier associated with the 
particular printer, 

a graphical user interface operable to present screens of 
information to users of the system, the screens includ- 
ing fields containing textual material; 

a grammar file storage system operable to store at least 
one grammar file containing field definition data oper- 
able to specify the textual material to be presented to 
the user through the graphical user interface; and 
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the execution control processor being operable to select 
and use a grammar file stored by the grammar file 
storage system associated with a particular user of the 
system in response to the user identification input by 
the particular user of the system, the selected grammar 
file uniquely specifying the textual material to be 
presented to the particular user, the execution control 
processor being further operable to allow editing of the 
field definition data in the grammar file according to the 
needs of a particular installation of the data processing 
system and the particular user, to thereby customize the 
grammar file storage system associated with the par- 
ticular installation. 

12. The data processing system of claim 11, wherein the 
security processor is operable to direct the presentation of 
options available to the user through the graphical user 
interface in response to the user identification input by the 
particular user of the system. 

13. The data processing system of claim 11, wherein the 
secure font comprises a magnetic ink character recognition 
font, and wherein the printer is operable to transmit infor- 
mation identifying printer errors to the execution control 
processor in response to an occurrence of errors during the 
operation of the printer. 

14. A method for processing financial instruments using a 
data processing system, comprising the steps of: 

receiving a user identification from a user of the system; 

receiving information associated with a financial instru- 
ment input through a graphical user interface; 

storing the information associated with the financial 
instrument in a data base; 

comparing a unique identifier associated with a particular 
printer to a stored identifier to confirm an identity of the 
particular printer; 

automatically transmitting, in response to confirming the 
identity of the particular printer, a security code asso- 
ciated with the particular printer to the printer to access 
a secure font; 

transmitting the information associated with the financial 
instrument to the printer after the security code is 
confirmed; 

printing the financial instrument using the secure font and 
the information associated with the financial instru- 
ment; and 

receiving print status information from the printer. 

15. The method of claim 14, further including the steps of: 
selecting a grammar file associated with a particular user 

in response to the user identification; and 
loading the graphical user interface with textual material 
from the selected grammar file. 

16. The method of claim 14, further including the steps of: 
calculating a fee associated with the processing of a 

financial instrument; 
displaying the calculated fee to the user of the system; 
displaying a list of selectable reasons for adjusting the 

calculated fee to the user of the system; 
receiving a security authorization code and information 

indicating a reason for adjusting the calculated fee from 

the user; and 

storing information indicating an adjusted fee and the 
information indicating a reason for adjusting the cal- 
culated fee. 

17. The method of claim 14, further including the steps of: 
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establishing a communication path between the data pro- 
cessing system and a host computer system; and 

transmitting information associated with transactions pro- 
cessed by the data processing system to the host 
computer system through the communication path. 

18. The method of claim 14, further including the steps of: 

storing a plurality of help files comprising textual material 
for presentation to a user of the system; 



26 



selecting one of the plurality of help files in response to 
the user identification received from the user; and 

displaying textual material from the selected help file 
upon receiving a request from the user associated with 
the user identification. 

19. The method of claim 14, further including the step of 
receiving a password request from the printer. 
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ABSTRACT 



A system integrates credit card transactions into a financial 
management system used by a company to track and control 
budgets, etc. The system provides the controls and account- 
ing for credit card transactions found for other types of 
transactions within the financial management system. The 
invention limits the card transactions using various limits 
not available to a credit card issuer and ensures that the 
transactions comply the financial system controls. The trans- 
actions can be obligated prior to or during the actual 
transaction with the bank and thereby subjected to the 
controls of the financial management system. Obligated 
transactions can be authorized for immediate payment. The 
invention provides for the complete reconciliation of the 
credit card transactions with bank records after the transac- 
tions occur using the obligation function to capture the 
transaction before it occurs, even the transactions that are 
immediately paid. The system reconciles the transactions 
recorded by the bank with those recorded in the financial 
system and updates budget, plan, project, and ledger entries 
accordingly. The system also allows cardholders to identify 
disputes and track the correspondence with the card issuer 
over the dispute. 

30 Claims, 23 Drawing Sheets 
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SYSTEM INTEGRATING CREDIT CARD 
TRANSACTIONS INTO A FINANCIAL 
MANAGEMENT SYSTEM 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention is directed to a system that accounts 
for credit card transactions within a financial management 
system where credit card purchases are automatically rec- 
onciled to the proper accounts based on credit card number 
and, more particularly, to a system in which card transac- 
tions are subject to controls associated with internal financial 
system limits such as single purchase limits, account limits, 
budget limits, etc. which are independent of the credit card 
company issuer limits and which are set prior to the actual 
transaction. 

2. Description of the Related Art 

Credit card transactions are becoming an ever more 
prevalent method of making purchases by large 
organizations, particularly small purchases of consumer type 
items needed on an immediate basis. Organizations want to 
maintain control over the continuously growing number of 
these transactions. Such organizations typically operate a 
financial management system such as Momentum™ Finan- 
cials available from American Management Systems, Inc. 
(AMS). Typically, such systems record credit card activity 
after the fact. An interface reads the credit card files supplied 
by the credit card company and creates transactions within 
the system to reflect the purchases and provide for payment. 
Such systems do not provide for automatic internal controls. 
Typically, reconciliation for credit card transactions is a 
paper based process which requires each cardholder to 
review all of their own card transactions and compare them 
with vendor invoices or a personal ledger of credit card 
transactions that the individual keeps. 

What is needed is a system that provides the automatic 
controls and tools necessary to properly account for and 
manage credit card activity within a financial management 
system. 

SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a system 
that subjects credit card purchases to internal company 
credit limits and single purchase controls in addition to 
controls implemented by the credit card company. 

It is also an object of the present invention to subject 
credit card purchases to internal controls, including 
budgetary, financial planning, project and general ledger 
controls, prior to the occurrence of the actual transaction. 

It is another object of the present invention to provide a 
financial management system that completely tracks credit 
cardholders, individual credit limits and default accounting 
codes for each credit card authorized within the financial 
management system. 

It is an additional object of the present invention to 
provide for the accounting of credit card transactions 
through all stages of the transaction including requisition 
and/or obligation which precede the actual card transaction 
through to payment to the credit card company. 

It is a further object of the present invention to provide for 
automated handling of disputes over card purchases. 

It is an object of the present invention to provide a system 
that automatically reconciles the recorded financial transac- 
tions and the card activity as recorded by the card company. 

It is another object of the present invention to provide 
access to credit and information in the financial system to 
cardholders through the Internet. 
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The above objects can be attained by a system that 
controls and accounts for credit card transactions within a 
financial management system. The invention places limits 
on the card transactions and ensures that the transactions 

5 comply with budget, financial planning and general ledger 
controls. The transactions can be obligated prior to or during 
the actual transaction with the bank and thereby subjected to 
the controls of the financial management system. The inven- 
tion provides for the complete reconciliation of the credit 

10 card transactions with bank records after the transactions 
occur. The system automatically reconciles the transactions 
recorded by the bank with those recorded in the financial 
system and updates budgets, plans, projects, and general 
ledger entries accordingly. 

15 These together with other objects and advantages, which 
will be subsequently apparent, reside in the details of 
construction and operation as more fully hereinafter 
described and claimed, reference being had to the accom- 
panying drawings forming a part hereof, wherein like 

2 0 numerals refer to like parts throughout. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 illustrates an architecture of the present invention. 
FIG. 2 shows a system model of a system according to the 
25 present invention. 

FIGS. 3-21 depicts the flow of processing when the 
purchase is not interactive. 

FIGS. 22 and 23 depict the flow of processing when the 
3 q transaction is interactive and approved by the financial 
management system at the time of the purchase from a 
vendor. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

35 

The present invention is directed to a system designed to 
provide for the control and accounting for credit card 
transactions within a financial management system. The 
financial management system would typically be used by a 

40 company seeking to track and control small purchases 
generally made via credit card. However, the system is also 
useful for state and federal government agencies that desire 
the same level of tracking. The system provides several 
levels of control for managing credit card transactions while 

45 also ensuring that the credit card transactions conform with 
the standard budget, financial planning, and general ledger 
controls used for standard financial transactions. 

Rather than simply accounting for credit card transactions 
after the fact, the system allows credit card transactions to be 

50 captured prior to the actual transaction with the bank, in the 
form of a requisition or an obligation, and subjected to the 
controls of the financial management system. Each card 
transaction is subjected to the standard financial manage- 
ment system controls for funds availability and security as 

55 well as controls for internally managing purchase limits for 
the employee cardholders. Transactions passing the controls 
are recorded using the appropriate general ledger accounts 
for the type of transaction. 
The system provides for the reconciliation of the credit 

60 card transactions with the bank records after the transactions 
actually occur. Any discrepancies are flagged and identified 
for user intervention. The system performs the necessary 
updates, including budget, financial planning, project, and 
general ledger updates and the liquidation of open items, to 

65 indicate that the transaction has been completed. The system 
also allows cardholders to identify disputes and track the 
dispute correspondence with the card issuer. 
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The system tracks each credit card and its relevant infor- 
mation including card number, cardholder, issuing company, 
expiration date, etc. The system allows internal credit limits 
including billing cycle limit and single purchase limits to be 
assigned for each credit card or a group of cards. These 5 
limits, which for convenience are called financial system 
limits, are to be enforced within the financial management 
system and operate independently of any credit limits 
imposed by the issuing company, which for convenience are 
called issuer limits. These limits are used when a transaction 10 
is to be approved at the time of a purchase, during obligation 
and approval. In addition to limits, the system allows a 
default accounting distribution or default account codes to 
be assigned to each card where effects of the transaction are 
recorded within the financial management system. 15 

With the integrated system of the present invention, an 
organization may require credit card purchases to be 
recorded in the financial system prior to their actual occur- 
rence. The system allows such anticipated credit card pur- 
chases to be recorded as obligations. As these obligation 20 
transactions are recorded, they are subjected to the standard 
financial controls, which may include budget, financial plan, 
and project funds availability checks, and the standard 
security controls, which may include user ID and password 
checks as well as secondary approvals based on the trans- 25 
action dollar amount and/or the type of goods to be pur- 
chased. 

When an organization uses the feature of obligating credit 
card purchases before they occur, the system tracks each 
anticipated purchase and stores the information needed to 30 
later reconcile the purchase with the credit card statement. 
As obligations for credit card purchases are processed, the 
system verifies that the credit card's single purchase limit 
and billing cycle purchase limit are not exceeded. 

An important element of the system is the automated 
reconciliation function. For each billing cycle, the credit 
card company provides an electronic file with the details of 
the credit card purchases, essentially the credit card state- 
ment. The system automatically loads the contents of the 4Q 
statements file into a database and allow users to reconcile 
purchases, register disputes, and/or trigger payments to the 
credit card company. 

When an organization employs the model of committing 
or obligating credit card purchases before the transaction is 45 
received from the bank, the system performs an automatic 
reconciliation between the outstanding requisitions and obli- 
gations in the system and the credit card statement records 
received from the bank or credit card company. When a 
match is found, the credit card transaction is marked as 50 
reconciled and eligible for payment. The system is flexible 
in that the organization can determine if the reconciled 
transactions can be paid upon reconciliation or whether the 
credit cardholder or his supervisor must still approve the 
actual payment of the transaction. 55 

At the time a credit card transaction is reconciled and/or 
approved, the user has the opportunity to alter the internal 
accounting codes (or override the default codes) associated 
with the transaction. If payment for the credit card transac- 
tion has already been made and the accounting codes have 60 
been altered, the system backs out the updates associated 
with the original accounting codes and performs the updates 
needed for the new accounting codes. The back-out and 
re-do of the updates ensures that the proper budgets, finan- 
cial plans, projects, and general ledger account balances 65 
have been updated to reflect the true accounting codes of the 
credit card transaction. 
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An organization has the option to immediately pay the 
credit card company upon receipt of the statement informa- 
tion or to delay payment until each credit card transaction is 
reconciled by the actual purchaser. When immediate pay- 
ment is chosen, the system generates payment authorizations 
which are processed to allow for the disbursement of funds 
through the organization's own payment authority, such as 
the company treasurer or if the payment authority is the U.S. 
Treasury to authorize a disbursement through the U.S. 
Treasury's electronic payments and checks systems. When 
the immediate payment is not used, payments are ware- 
housed until the credit card transactions have been recon- 
ciled using information from either the initial obligation 
and/or the statement received from the credit card company. 

When the payment authorizations are generated and 
processed, the accounting codes are taken from the credit 
card set-up information. This allows the appropriate 
budgets, projects, general ledger accounts, and financial 
plans to be updated as the payments and subsequent dis- 
bursements are processed. 

The present invention is preferably implemented in an 
application architecture 10 as depicted in FIG. 1. Work- 
stations 12 interact, via a suitable interface program, with an 
application server 16 which accesses data of the financial 
management system within a database server system 18 
where a processor 20 accesses a financial system database 
22 stored within a disk array 24. The work-stations 12 can 
be typical desk top computers. The work-stations 12 can be 
connected to the system 16 directly or via a packet-switched 
network, such as the Internet. Typically, a company (or 
possibly a government agency) will have a multitude of such 
work-stations 12, allowing each employee access to the 
system. The database server 20 can also be similarly con- 
nected via such a packet-switched network. 

Although not shown in this figure, the system 10 com- 
municates with a credit card issuer 36 as well as a payment 
authority 46 (see FIG. 2). Typically, these communications 
are via a magnetic media, such as tape. However, direct 
connections or connections over a packet-switched network 
are also within the architecture contemplated by the system 
described herein. 

The architecture 10 preferably executes a financial man- 
agement system, such as Momentum ™ Financials available 
from AMS, that performs basic financial management opera- 
tions such as comparing purchases to budgets, etc. A suitable 
operating system for the architecture 10 is the UNIX oper- 
ating system or the WindowsNT operating system while a 
suitable set of programming languages include using C++ 
for server components, Smalltalk for the screen (desk top) 
components and JAVA for the Web version of the screen 
components. The computers of the architecture include the 
computer readable storage (RAM, ROM disks, etc.) upon 
which the processes and data structures of the present 
invention can be stored and distributed to customers, if 
desired. The processes can also be distributed to purchasers 
via downloading over a network, such as a packet switched 
network using an electromagnetic wave, such as a carrier 
wave. 

The credit card financial management system of the 
invention operates in an environment having a system model 
30, as shown in FIG. 2, where an employee 32 is issued a 
credit card 34 by a credit card issuer 36, such as a bank, as 
authorized by the company/employer 38 of the employee 32. 
The employer 38 can be a corporation or a government 
agency, such as the U.S. Patent and Trademark Office. The 
employer 38 uses the system of the present invention. 
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Typically, the employee 32 makes a credit card purchase 
with a vendor 37. The vendor 37 communicates the trans- 
action to the issuer 36 and the purchase is communicated to 
the company 38 by the issuer 36 via an electronic credit card 
statement 40. If necessary, the statement is used by the 
system to reconcile the purchase, with assistance of the 
employee 32 via an Internet session, for example, or to 
create an electronic dispute record 42 communicated to the 
issuer 36. When the purchase is reconciled electronic pay- 
ment authorization information 44 is communicated to a 
payment authority 46, such as a company treasurer or the 
U.S. Treasury. The payment authority 48 makes a payment 
(electronic or check) to the issuer 36, 

Prior to discussing the processes of the present invention 
in detail with respect to FIGS. 3-23, three types of credit 
card transactions that the system is designed to handle will 
be briefly discussed. 

Prior to credit card transactions being processed by the 
credit card financial management system, information needs 
to be provided to the system that will authorize a particular 
person and credit card to initiate transactions within the 
system. This card set-up is performed from one of work- 
stations 12 where information associated with the cardhold- 
ers name, the card number, the card issuer, purchase limits 
for a billing cycle and a single purchase, default account 
codes, processing rules (approvals) for this card, etc. are 
stored in the system. Some of this information, such as credit 
card number is obtained from the credit card bank 36, either 
via a paper/verbal communication with the bank 36 or via an 
electronic transaction with the bank 36. If the card transac- 
tions are to be approved at the time of purchase by the 
financial management system, this information is commu- 
nicated to the bank 36. 

In a first type of transaction, which for convenience is 
called an non-pre approved transaction, the cardholder pur- 
chases an item at a vendor 37 and, after the normal pro- 
cessing by the bank or credit card issuer 36, the bank 36 
transmits the transaction to the system. The purchase trans- 
action can arrive on a recording medium such as a traditional 
tape or as an electronic transaction over a communication 
network, such as a packet-switched network, as previously 
mentioned. The system automatically checks the transaction 
against all limits, and if the transaction meets all the 
approval criteria for this card, it processes that transaction 
using the rules designated for this card debiting the default 
accounts and issuing a payment authorization to the payment 
authority 46. The payment authority 46 makes the payment 
to the bank 36. If the transaction does not pass the internal 
checks, such as exceeding an internal company single pur- 
chase limit or would cause a budget item to be exceeded, the 
transaction can be flagged for internal resolution. The sys- 
tem can be configured to go ahead and authorize payment for 
the purchase or it can be held. In either case the cardholder, 
supervisor or other person with sufficient authority is noti- 
fied by an appropriate message. This person accesses the 
system and performs the operations necessary to resolve the 
transaction. 

In a second type of transaction called a pre approved 
transaction, the cardholder accesses the system through the 
work-station 12 and creates an obligation. An obligation is 
a transaction in which the amount of the transaction can be 
anticipated, the product to be purchased is known, the 
vendor is known, the account codes of the accounts/budgets 
affected by the transaction are known, etc., and one which 
has been approved. It is a transaction for which the system 
recognizes that approval for the credit card purchase has 
been previously authorized. The user then makes the pur- 
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chase at the vendor 37 and when the purchase transaction 
arrives from the bank 36, the system essentially transmits a 
payment authorization to the payment authority 46 and then 
reconciles the transaction by debiting the proper accounts, 
5 etc. If a dispute arises, a mechanism is available to credit the 
company 38 for the transaction in a later payment authori- 
zation. 

In a third type of transaction, called an interactive 
transaction, at the time of the purchase at the vendor 37, after 

10 the purchase has passed the limit processing of the bank 36 
but before the bank 36 sends an approval back to the vendor 
37, the bank 36 sends a approval request to the system. This 
approval request includes the card number, the amount of the 
purchase, the vendor and a product/service code (typically 

15 one designated by the U.S. government or some other 
entity). The system, at a minimum, checks the amount of the 
purchase against the internal card limits set by the cardhold- 
er's company 38 and returns an approval or disapproval 
response based on the determination. The system before 

20 approving the purchase can make checks other than just 
checking the credit card internal limit. For example, using 
the product code, the system can also check to see if the 
transaction is of a type that matches an authorized account 
for this cardholder. For example, if the product code indi- 

25 cates that a personal computer is being purchased but the 
cardholder is not authorized to spend money from a com- 
puter purchase account, the transaction can be disapproved. 
When the actual purchase transaction arrives later at the 
system from the bank 36, the transaction is processed as 

30 previously discussed. 

This third type of transaction allows additional features to 
be provided for a company 38. For example, when a 
transaction has been pre approved by the creation of an 
obligation and the approval request arrives from the bank 36, 
the system, in addition to approving the transaction, can 
substantially immediately send a payment authorization to 
the payment authority 46 which could pay the bank 36 
before the end of the billing cycle in which the actual 
transaction occurred. Such early payment would allow the 

40 bank 36 to provide the company 38 with more favorable 
credit card credit terms or discounts. 

The details of the processes that allow these transactions 
to be processed by the system of the invention are discussed 
below. 

45 

The credit card purchasing process can begin, as depicted 
in FIG. 3, with the employee 32 creating 102 an obligation 
for a credit card purchase where the system checks to 
determine whether the purchase is within the various pur- 

50 chase and budget limits. This obligation creation step inputs 
the credit card information as well as the necessary account- 
ing information. This processing 102 will be discussed in 
more detail with respect to FIG. 4. Next, the system deter- 
mines 104 whether the purchase has been approved. If not, 

55 the obligation is canceled 106 and processing ends 108. 
If the obligation has been approved, the system then 
determines 110 whether the credit card issuer provides an 
electronic credit card statement. If so, the transaction can be 
processed electronically and if not a manual reconciliation 

60 process is performed 112 where the employee 32, and others 
necessary to the reconciliation process, are provided with 
information, via screen displays on the work-stations 12, 
allowing the employee 32 to confirm whether the purchase 
is correct and should be paid. In this process the employee 

65 32 is presented with the credit card statement, reviews the 
statement against purchase receipts and other personal notes 
and indicates whether the purchase is correct or in dispute. 
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The purchase can be in dispute for a number of different 
reasons, such as the purchase amount on the statement being 
incorrect due to returns of part of the purchase which is a 
dispute with the bank 36 or because the employee is not 
satisfied with the purchased items which is a dispute with the 5 
vendor 37. 

If the bank 36 does provide electronic statements 40, the 
system processes 114 the credit card statements file. This 
step 114 can also be an entry point into the processes of the 
invention. This operation 114 essentially maps the format of 30 
the statement to the format of the records of the financial 
management system, such as Momentum™ Financials. This 
process 114 will be discussed in more detail with respect to 
FIG. 7. Next, the system generates 116 immediate payments 
on the credit card, if any are to be generated, which results 15 
in a payment authorization being sent to the payment 
authority 46 based on an unreconciled statement rather than 
after reconciliation has occurred. Any disputes are handled 
via credits whenever payment is generated immediately 
upon receipt of the statement. By being able to pay for the 20 
transactions on the statement substantially immediately, the 
company 38 can seek better credit terms or a discount. In this 
process, if the card issuer 36 provides discounts for early 
payment, the "income" associated with the discount can also 
be calculated. This process 116 is discussed in more detail 1S 
with respect to FIG. 10. Automatic reconciliation 118 occurs 
next and includes essentially matching the amounts of 
obligations to the credit card statement transactions. If 
matches exist the credit card transaction is marked as 
reconciled and otherwise it is manually reconciled. The 30 
process 118 is discussed in more detail using FIG. 12. 

Once reconciliation has been performed, the system deter- 
mines 120 whether any disputes exist. If so, the system 
generates 122 a dispute, which identifies the card number, 
the transaction, the amount, the type of dispute (vendor or 35 
bank) and the employee's justification for the dispute, such 
as double debits. The dispute is then sent to the bank 36. This 
process 122 will be discussed in more detail using FIG. 15. 
The system then generates 124 a payment credit (or offset) 
for the credit card for the transactions in dispute which is 40 
held until a later processing cycle when the dispute can be 
resolved. This operation 124 is discussed later herein with 
respect to FIG. 17. 

If there are no disputes, the system performs a second 
approval process 126 where the credit cardholder 32 can 45 
review and approve (or disapprove — reject) the transactions, 
as long as they are within the employee's approval limits. 
The employee can also change the account codes indicating 
where the transaction is to be posted. A credit card group 
holder, a person at the company 38 responsible for a group 50 
of employees having credits cards, can also review and 
approve (or disapprove) the transactions at a different limit 
level. This process 126 will be discussed in more detail with 
respect to FIG. 18. 

Next,, the system generates 128 payments and, if 55 
necessary, adjusts the account codes of the credit card 
transaction with respect to what accounts within the finan- 
cial management system are affected. A transaction which is 
set up for immediate payment is paid using a set of default 
account codes that are set at the time the credit card is issued 60 
to the employee 32. When the transaction is reviewed for 
reconciliation and/or approval the employee may have 
changed the account codes to allocate the purchase to an 
account that is different from the default account. This 
operation 128 essentially internally backs the transaction out 65 
of the default accounts within the financial management 
system and enters it into the accounts selected during the 
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reconciliation and approval process. These processes 128 
will be discussed in more detail later with respect to FIG. 21. 

The obligation process 102 starts with the employee 
entering 140 the transaction information via the work-station 
12 as illustrated in FIG. 4. This information, if it is an 
itemized or detailed obligation, can include the amount of 
the intended purchase, the vendor, the type of purchase 
(typically using the standard government codes for products/ 
services), the account codes for the purchase, etc. If the 
obligation is being created after the purchase, such as when 
the employee 32 has made a telephone purchase with the 
credit card, the information can also include the approval 
code issued to the vendor 37 by the bank 36 and other 
information that may be included on an invoice, such as 
date, time, product or service code, vendor and vendor 
location. This information is checked 142 for validity using 
the standard validation criteria and processes of the financial 
management system, such as Momentum™ Financials. 
Additionally, checks of the budget, financial plan, and 
project balances associated with the accounts are made to 
determine whether the purchase is within the funding asso- 
ciated with the employee and the accounts. Next, the system 
determines 144 whether the information being processed 
includes an actual credit card number or an alias. Aliases are 
used when the access to the actual card number needs to be 
restricted, such as when a clerk is entering information from 
an obligation form. 

If neither an alias nor a credit card number is present, the 
system performs 146 standard obligation updates as typi- 
cally occur in a financial management system, such as 
Momentum™ Financials, and obligation processing is com- 
plete 148. 

If an alias is present, the system accesses the credit card 
table to infer or determine the true credit card number and 
continue processing. The credit card table holds information 
and processing rules pertaining to the individual credit cards 
such as card number, alias, type, approval group, effective 
dates, active flag, holder, expiration date, single purchase 
limit, bill cycle purchase timit, default dispute accounting 
codes, default payment accounting codes, etc. If the alias is 
invalid and the credit card number cannot be determined, the 
system issues an invalid purchase attempt message to the 
employee 32. If an alias or a credit card number is being 
used, the system verifies the obligation against the credit 
card authorization limits for the employee for single pur- 
chases and purchases within a billing cycle as well as 
verifying 150 that the rules for the credit card are not being 
violated, such as the type of product eligible for purchase, 
and which will be discussed in more detail using FIG. 5. 
Next, the system determines 152, from the verification 
processing, whether the purchase is valid. If not, the system 
issues 154 an invalid purchase attempt message to the 
employee 32. If the purchase is valid, credit card updates 
156 are performed 156 which essentially includes allocating 
an obligation amount and an obligation identifier within the 
financial management system, thereby indicating that an 
outstanding obligation exists (a set aside or allocation of an 
amount of purchase authority). This obligation becomes the 
basis for a reconciliation when the credit card statement 
arrives from the bank 36. The updating 156 will be discussed 
in more detail with respect to FIG. 6. 

In verifying the credit card obligation against rules and 
limits 150, the system first determines 170 whether an alias 
has been entered. If so, alias records in the credit card table 
are accessed 172 to determine 174 whether the alias is valid. 
If not, a message is issued indicating that an error in the 
entry of the alias has occurred and processing ends 178. If 
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the alias is valid, the credit card number is mapped or 
determined 180 from the alias and the credit card number 
records in the credit card table are accessed 182 to determine 
whether the card number is valid. For example, a card can 
have a valid alias but the card can be beyond the expiration S 
date for the card number. When the card number is not valid, 
the system issues 186 an appropriate message and ends 178 
transaction processing. 

If the card number is valid, the system then determines 
188 whether the card has been set up to use default account 10 
codes. If so, the default codes are set 190 for this obligation 
and these defaults can be displayed to the employee 32 at the 
work-station 12 to allow them to be changed. 

After processing with respect to the account codes, the 
system checks 192 the amount of the obligation to determine 15 
if it exceeds the single purchase limit for the card and if so 
issues 194 an appropriate message. 

To determine whether a billing cycle limit for the card has 
been exceeded, the system accesses 196 a billing cycle 2Q 
summary table to obtain the current billing cycle informa- 
tion for this card and adds 198 the obligation amount to the 
total. If this total exceeds (200) the cycle limit for the card, 
a message is supplied 202 to the employee 32 indicating that 
the cycle limit has been exceeded. 25 

In the credit card purchase updates process 156, the 
system processes individual obligations in a loop 220-222, 
as depicted in FIG. 6, where each cycle of the loop corre- 
sponds to an obligation that has been created and, when all 
obligations have been processed, processing ends 224. The 30 
process, however, starts with the system inserting 226 a 
record in the credit card purchase table. The credit card 
purchase table holds information for each credit card pur- 
chase entered into the financial system using the purchase 
orders or purchase order forms, such as credit card number, 35 
purchase order document number, charge date, authorization 
code, vendor name, city and state, reconciliation status, etc. 
This insertion operation inserts an entry for the current 
transaction (an obligation transaction as opposed to an actual 
credit card purchase transaction which is received from the 40 
bank 36) for this credit card in the table that stores the 
purchase activity for the cards. In this situation the entry 
includes card number, amount and obligation identifier. 
Next, the system determines 228 whether there is a billing 
cycle record for this card and, if there is no cycle record, the 45 
system creates 230 a record which includes the information 
noted above. The system then adds 232 the amount to the 
card total for the cycle. The system then determines 234 
whether a group level billing cycle summary table entry 
exists for this card, if not an entry is created 236 at the group 50 
level and the amount is added 237 to the group total. The 
loop is then entered and for each obligation line, the record 
is inserted 238 in the credit card purchase detail table and 
inserted 239 in the credit card activity table. The credit card 
purchase detail table holds detailed information for each 55 
credit card purchase entered into the financial system using 
the purchase order forms, such as credit card number, 
purchase order document number, purchase order line 
number, purchase amount, reconciliation/liquidation 
amount, etc. Each entry in this table corresponds to a line or 60 
item on a purchase order. 

The credit card purchase process where the credit card 
statements are processed 114, as depicted in FIG. 7, begins 
by accessing 240 the credit card statements table with the 
statement ID. The credit card statement table holds infor- 65 
mation for each credit card statement that has been received 
from the credit card issuing organization such as statement 
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number, payment due date, total amount due, credit card 
type, prepayment made flag, prepayment authorization 
document number, etc. The system then determines 241 
whether entry for this statement exists in the table. If so, an 
error message is issued 242 and the processing ends 243. If 
not, an entry is created 244 in the table and the statement 
details are processed 245 which will be discussed in more 
detail with respect to FIG. 8. Once the statement details are 
processed, the statement table is updated 246 and the sta- 
tistics for the processed statement are catalogued and printed 
247. 

The processing 245 of the statement details, as depicted in 
FIG. 8, is performed within a loop 248-249 where the 
records of the statement are processed one at a time. 

In this loop, the system accesses 250 the credit card table 
to obtain that credit card number on the statement and 
determines 251 whether the number in the statement is valid. 
If the number is not valid, an error message is issued 252 and 
a record is written 253 to an error file indicating the type of 
error. This file will be sent to the bank 36 at the end of 
processing. If the card number is valid, the system maps 254 
the fields of the statement record to the fields of the 
statement detail table for the credit card maintained by the 
system. This credit card statement detail table holds detail 
information for each credit card statement that has been 
received from the credit card issuing organization including 
statement number, statement line number, credit card 
number, transaction number, charge date, posting date, 
authorization code, vendor name, city and state, payment 
accounting codes, charge amount, reconciled amount, pre- 
payment authorization line number, reconciliation status, 
etc. Each entry in this table corresponds to an individual 
credit card transaction reported on the statement. An 
optional credit card statement item table can also be used 
and holds item information for each credit card transaction 
included in the statement that has been received from the 
credit card issuing organization, such as statement number, 
statement line number, detail line number, product/service 
code, standard industrial code, description, amount, etc. This 
information can be important for monitoring purchasing 
trends and identifying credit card abuse. A key to the 
statement detail table is then assembled 255 using the 
statement number, credit card number and the credit card 
transaction number. The credit card statement table is then 
accessed 256 using the key to determine 257 whether the 
record for the purchase already exists in the table. If so, it is 
a duplicate purchase and an error is issued 258. If the record 
does not exist, the table is updated 259 with the entry and 
statistics on the contents of the table are updated 260 to 
reflect such things as the number and types of purchases that 
were included in each statement file from the bank 36. Next, 
the item details of the statement are processed 261 which 
will be discussed below with respect to FIG. 9. 

The item details process 261 operates on a per record 
basis in a loop 262-263 as shown in FIG. 9. The system 
determines 264 whether the record includes data and an item 
level. If not, the next record is read 263. If so, the record 
fields are mapped 265 to the detail table. Next, a key is 
created 266 and used to access 267 the detail table to 
determine whether an entry exists in the table. If so, the entry 
is updated 269 with the dollar amount. If not, the table is 
updated 270 with the entry. Lastly, the statistics for the 
statement are updated 271. 

In generating immediate payments 116, as depicted in 
FIG. 10, the system operates in a loop 280-281 to process 
each entry in the credit card statements table and payment 
authorizations are assembled. At the end of this loop the 
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system processes 282 payment authorizations for each card 
issued and sends them to the payment authority 48 for 
payment and terminates 283 this operation. In the loop the 
system first determines 284 whether the statement entry is to 
be processed in the designated billing cycle. The processing 5 
cycle for the company 38 may not match the billing cycle for 
the bank 36 and only those transactions that fall within the 
processing cycle of the company 38 are currently processed. 
If the entry is to be processed, the system accesses 285 the 
credit card type table to obtain the type for the card. The 10 
credit card type table holds information and processing 
rules, such as whether immediate payment is applicable, 
pertaining to the valid types of credit cards (e.g., Diner's 
Club, AMEX, IMPAC) as well as credit card type, number 
alias, vendor, effective dates, credit card name, active flag, 15 
vendor payment address, vendor dispute address, reconcili- 
ation method, payment authorization generation flag, default 
payment accounting codes, amount tolerance, date 
tolerance, billing cycle end day, etc. The rules for credit card 
processing are preferably set up based on the type of card. 10 
Some cards must be paid at the end of the billing cycle, these 
type cards typically charge no interest and would be set up 
for immediate payment. If the type is not set 286 for 
immediate payment, the processing moves to the next entry. 
Otherwise, a payment authorization (form) is created 287 for 2 s 
this statement. Next, the immediate payment lines are gen- 
erated 288, as will be discussed in more detail with respect 
to FIG. 11. If a discount is to be applied to the immediate 
payment, the discount terms are established for the credit 
card issuer in a vendor table. For example, a 2% discount if 30 
paid within two days. The payment authorization and sub- 
sequent disbursing processing calculate the discount and 
update the budgets and general ledger with the discount. 
Then, the statement table is updated 289 to include a 
prepayment document number entry and reflect that the 35 
entry has been paid. 

As depicted in FIG. 11, the generation 288 of the imme- 
diate payment lines includes a loop 284-285 that processes 
entries in the detail table until the end of the table is reached 
and processing is terminated 286. The first step is to create 40 
287 a payment authorization line or specific authorization 
item in the authorization and set 288 the type for the item to 
"prepayment". Next, a determination is made 289 as to 
whether the card has default account codes. If so, the codes 
are added 290 to the payment authorization line or item. 45 
Otherwise, the account codes for the card type are provided 
291 for the payment authorization line. The authorization is 
then added 292 to the file for the particular bank 36 issuing 
the card and the detail table is updated 293 with the 
authorization line number. 50 

During automated reconciliation 118, as shown in FIG. 
12, the system operates in another loop 320-322 where each 
entry in the statement table is processed until the end is 
reached and processing terminates 324. The first step is to 
access 326 the credit card type table to obtain the type for the 55 
card. Based on the type, a determination 328 is made as to 
whether statement or obligation reconciliation can be per- 
formed and, if not, the manual process is performed 112 (see 
also FIG. 3). The system then enters a loop 330-332 where 
the entries in the detail table are processed. In this loop, the 60 
systems attempts to find 334 a matching obligation which 
will be discussed in more detail using FIG. 13. If a match is 
not found (336), the next entry is processed. If a match is 
found, a determination 338 is made as to whether the 
purchase has been disputed. If not, reconciliation updates are 65 
performed 339, as will be described with respect to FIG. 14, 
and the credit card statement table is reconciled. 



,279 Bl 

12 

The matching obligation process 334 (FIG. 13) also 
includes a loop 340-342 where all the open billing cycles are 
reviewed for a matching transaction. First, a determination 
344 is made as to whether the statement includes an approval 
code which was issued at the time of the purchase when the 
vendor 37 requested approval from the bank 36. If so, a 
search 346 of the credit card obligation table is performed 
using the approval code, card number and billing cycle. A 
determination is then made 358 as to whether a match exists. 
If not the table is searched 350 with the amount, card number 
and billing cycle. Again a determination 352 is made as to 
a match. If there is no match the card number and billing 
cycle are used for a search 354 of the purchase table. At the 
end of the search match loop 340-342 the system determines 
356 whether a matching obligation has been found. If not, 
the entry is updated 358 as unreconciled and to be processed 
via a manual reconciliation later and processing ends 360. If 
a match has been found the vendor is checked 362 for a 
match. If there is none, an error message is issued and the 
entry is marked 366 reconciled with errors. The user can also 
approve the transaction to allow it to be paid or a dispute can 
be lodged or setup. When there is a vendor match, the 
purchase amount and purchase date are compared to the 
corresponding tolerances for the credit card type maintained 
in the credit card table. If the date or amount is outside (370) 
the tolerance, the system issues 372 an error message 
indicating that the obligation does not match and the entry 
is marked as reconciled with errors. If the amount is within 
the tolerance, the entry in the obligation is updated 374 as 
reconciled. 

During the reconciliation update process 339 (see FIG. 
14) the purchase table entry being processed is updated 380 
to a status of reconciled and the purchase detail table is 
updated 382 with the reconciled amount. The statement table 
is also updated 384 by adding the amount to any previous 
reconciled amount accumulated, followed by doing a similar 
addition to the statement detail table. Next, a reconciliation 
table entry is created 388 linking the purchase and statement 
details. The credit card reconciliation table typically holds 
the results of all reconciliations, including both automated 
and user-driven reconciliation activity, such as statement 
number, statement line number, dispute number, purchase 
document number, purchase document line number, credit 
card number, accounting codes, reconciled amount, pur- 
chase partial/final flag, distribution method flag, payment 
document number, payment document line number, prepay- 
ment reversal document number, prepayment reversal docu- 
ment line number, status, etc. A determination 390 is then 
made as to whether the purchase amount equals the state- 
ment amount and, if so, the new entry in the table is set 392 
to a final reconciliation status, otherwise, it is set 394 to a 
partial reconciled status. If the type of credit card requires 
(396) approval the entry is set 398 to a status requiring 
approval, otherwise, it is set 400 to a status where approval 
is not required. The update processing then ends 402. 

During dispute processing 122, the system allows the 
employee 32 to enter 420 and then accepts 421 the criteria 
to select items in the statement detail table for display, as 
illustrated in FIG. 15. This can be another entry point into 
the processes of the present invention. That is, the employee 
32 can initiate the dispute process at any time. The criteria 
entered by the employee 32 could include a vendor 
identifier, purchase range limits and other information which 
will help identify a transaction. This information is used to 
search 422 the statement detail table. If a match is not found 
(423), a message is supplied 424 to the employee 32 and the 
employee can enter/change the search criteria. When the 
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questioned item is found, the employee 32 can enter 425 the 
justification for the dispute which is used to update the 
statements table indicating that the item is in dispute, 
thereby acknowledging and tracking disputes over credit 
card purchases. As an option the user can accept 426 the 
users accounting codes for the dispute. The system then 
performs 427 the updates (see FIG. 16) associated with the 
dispute. If an on-line connection is available (428) to the 
bank 36, the system sends 429 a dispute message to the bank 
36. Otherwise, the dispute is written 430 into a dispute file, 
statistics for the statement are updated 431 and dispute 
processing ends 432. As an extension of the above, the user 
may also initiate a dispute against an obligation. The dispute 
still needs to be matched against a statement, but this allows 
the end-user to record a dispute at the earliest possible time. 
For example, if the goods received are defective, but the 
credit card statement has not yet been received. 

During the dispute update operation 427 (see FIG. 16), the 
system generates 434 a unique identifier for the dispute 
either with the user or automatically. A dispute table entry is 
then created 436 with the justification and the amount. The 
credit card dispute table, an optional table, holds detailed 
item information for each credit card transaction included in 
the statement received from the credit card issuing 
organization, such as credit card number, dispute number, 
dispute amount, reconciled amount, justification, dispute 
date, dispute accounting codes, reconciliation status, etc. 
Next, a linking entry in the reconciliation table to the dispute 
is created 438. The system then determines 439 whether the 
statement has been paid by looking at the payment status in 
the reconciliation table entry. If not, the reconciliation table 
is updated to indicate that the entry is awaiting 
reconciliation, otherwise, the entry is set 441 as awaiting 
payment. The statement detail table is then updated 442 and 
update processing of the disputes ends 443. 

A loop 460-462 in the credit process 124 processes each 
entry in the credit card reconciliation table and starts, as 
shown in FIG. 17, with determining 464 whether the entry 
has been marked as disputed. If not, processing ends 468. If 
so, the statement is checked 470 to determine whether the 
entry has been marked as paid as can occur when the 
payments are generated immediately (see 116). In the case 
where the payment has been made and it is in dispute, a 
no-check authorization or credit is made 472 through the 
payment authorization for the entry to prevent the entry from 
being paid, followed by creating 474 a negative expenditure 
line or item in the credit card statement detail table for the 
account code which backs out the previous payment. Next, 
a positive prepayment or advance is created 476 for the 
credit card table, essentially showing an over payment to the 
bank or card issuer 36. Next, the reconciliation table is 
updated 478 with an identifier for the reversal and to indicate 
480 that the entry is awaiting reconciliation. Then, the 
positive payment is authorization is processed 482, thereby 
deducting the amount from the money owed to the bank 36. 

FIG. 18 illustrates the approval process 126 and starts 
with applying 500 the cardholder approvals which will be 
discussed in more detail using FIG. 19. Acheck is then made 
502 as to whether the entry has cardholder approval and if 
not the entry is bypassed 504 and processing ends 506. 
When the entry has been approved, the employee 32 can 
change 508 the account codes after which the group 
approval process is performed 510 (see FIG. 20). Next, a 
determination 512 is made as to whether the reconciliation 
table has all the necessary approvals and, if so, the table is 
updated 514 as fully approved. 

The cardholder approval process 500 (FIG. 19) includes 
an outer loop 530-532 which loops on the holders credit 
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cards within which the credit card statement entries for each 
card are displayed 536 and an inner loop 538-540 which 
exists for processing each entry in the statement. As each 
entry is processed, the employee 32 is first asked 542 

5 whether the purchase is approved. If not, the entry enters the 
dispute process 122 (see FIG. 15). If the purchase is 
approved, a check is made 544 concerning the card single 
purchase limit. If the limit is exceeded, a message is issued 
546 and the entry is updated 548 as requiring special 

10 handling. A test of the billing cycle limit is also made 550 
which, if exceeded, results in a message 560 and special 
handling 548. When no limits are exceeded, the entry is 
updated 562 as approved. 

The process 510 for group approval, as depicted in FIG. 

15 20, includes most of the same steps as the cardholder 
approval process of FIG. 19 but the approvals are at the 
group level limits and the person approving the purchase is 
presented all of the statement entries for all of the cards in 
the group. For convenience, these steps 580-602 will not be 

20 discussed in detail. 

In generating credit card payments and adjusting the 
account codes 128 the system process in a loop 620-622 (see 
FIG. 21) where approved entries in the credit card state- 
ments table are processed until all the statements have been 

25 processed, at which time the credits are processed 624 for 
payment authorization and processing ends 626. In the loop, 
each entry is examined 628 to determine whether it is in the 
cycle to be processed. If so, the system accesses 630 the 
credit card type table and obtains the credit card type using 

30 the card number. If the card is the type where post recon- 
ciliation is performed (632), the system creates 634 a 
payment authorization with the account codes of the table 
entry for the card. When the credit card is not the type for 
post reconciliation, the system checks 636 as to whether it 

35 is an immediate payment type. If the payment is immediate, 
the back-out of the immediate payment needs to be per- 
formed. To do this a payment authorization with a positive 
payment and the statement account codes is created 638 
followed by creation 640 of a negative authorization having 

40 the default account codes. The authorizations are then added 
642 to the list of authorizations for the bank 36 and the status 
of the entry on the reconciliation table is updated 644 as 
paid. 

The manual or user-driven reconciliation process 112 uses 

45 a typical manual entry operation found in many financial 
management systems where the user is presented with a 
display and allowed to make entries or changes to certain 
items in the display. The process 112 handles four primary 
cases. In the first case, the organization uses purchase orders 

50 in the financial system to record credit purchases, and the 
bank provides electronic statements. In this case, the user is 
presented with a display of all unreconciled purchases in the 
statement detail table and allowed to view the purchases 
recorded on purchase orders and the transactions input from 

55 the electronic statement in parallel. The user is then able to 
reconcile the purchases with the transactions listed on the 
statement by performing matches and manually enter the 
reconciliation amount. In the second case, the organization 
uses purchase orders in the financial system to record credit 

60 card purchases, but the bank does not provide electronic 
statements. In this situation, the user is presented with a 
display of the purchases recorded on the purchase orders. 
The user is then able to reconcile the individual purchases 
with the transactions listed on the hard copy statement. For 

65 each purchase, the user can manually mark the purchase as 
reconciled and enter the reconciled amount. In the third case, 
the organization does not use purchase orders in the financial 
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system to record credit purchases, but the bank provides 
electronic statements. In thus case, the user is provided with 
the transaction information from the electronic statement 
(entries in the statement detail table). The user has the ability 
to reconcile a transaction by manually entering a reconcili- 
ation amount and/or dispute a transaction by entering a 
dispute amount and justification. In the last case, the orga- 
nization does not use purchase orders in the financial system 
to record credit purchases, and the bank does not provide 
electronic statements. In this case, the user enters the trans- 
actions from a hard-copy statement into the financial system. 
If while creating the entry the user marks it as reconciled, the 
entry can be handled by the payment generation process. It 
can also be marked as in dispute and handled via the dispute 
process. For each user-driven reconciliation performed 
online, the system, as previously discussed, updates the 
reconciliation status on the associated statement, purchase, 
and/or dispute entries and creates an entry in the reconcili- 
ation table that links the statement, purchase, and/or dispute 
entries and allow payment processing to occur. 

When the credit card transaction is to be approved by the 
financial management system interactively and in real-time 
at the time of the purchase from the vendor 37, the process 
of FIG. 3 is modified as depicted in FIG. 22. A message 
arrives from the bank 36 over a network, such as a packet 
switched network, and an automated obligation process 662, 
which will be discussed in more detail using FIG. 23, is 
performed. This step 662 is another entry point into the 
processes of the present invention. The message includes a 
transaction tag, the card number, the type of purchase, the 
amount, vendor name and vendor location. The system then 
checks 664 to determine whether the obligation was suc- 
cessful. If not, a failure message is sent 666 to the bank 36 
which the bank can use to disapprove the transaction at the 
vendor 37 by sending an appropriate message to the vendor 
37. For example, when the purchase amount exceeds the 
single purchase limit or the purchase is of a type of product, 
based on the product codes, that is not authorized for the 
default accounts for the card, a failure of approval or 
rejection can be generated. The message includes the trans- 
action tag and a flag indicating the transaction has not been 
approved. If the obligation is successful, a success or 
approval message is sent to the bank 36 which can then send 
an approval code to the vendor 37. The date, amount and 
transaction tags of approved transactions are stored during 
the obligation process for later reconciliation. Upon success 
the system can generate 116 an immediate payment (see 116 
FIG. 10), again allowing the company 38 to obtain most 
favorable credit terms or a discount. The remainder of the 
operations 120, 122, 124, 126, 128 and 108 have been 
previously discussed and will not be repeated for the sake of 
brevity. 

In processing an automated obligation 662, the system 
first maps 680 the message contents into the fields of the 
records of the financial management system, as shown in 
FIG. 23. Then the operations previously discussed and 
associated with an obligation are performed. For brevity 
these operations 142, 150, 152, 154, 156, 146 and 148 will 
not be discussed again. 

The many features and advantages of the invention are 
apparent from the detailed specification and, thus, it is 
intended by the appended claims to cover all such features 
and advantages of the invention which fall within the true 
spirit and scope of the invention. Further, since numerous 
modifications and changes will readily occur to those skilled 
in the art, it is not desired to limit the invention to the exact 
construction and operation illustrated and described, and 
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accordingly all suitable modifications and equivalents may 
be resorted to, falling within the scope of the invention. 
What is claimed is: 

1. An integration system associable with a credit card 
5 issuing system issuing credit cards to multiple users of an 

organization with each of the cards having issuer limits and 
said integration system comprising: 
an organization financial management system providing 
control and accounting for financial transactions of the 
10 multiple users within the management system, and 
providing financial system limits; and 
a credit card management system associated with the 
financial management system and the credit card issu- 
ing system, and providing spending control for credit 
15 card transactions using the financial system limits 
imposed by the organization and providing accounting 
for the credit card transactions within a general ledger 
of the financial management system. 

2. A system as recited in claim 1, wherein said credit card 
20 system checks the transactions against financial system 

employee limits imposed by the organization. 

3. A system as recited in claim 2, wherein the financial 
system limits include one of single purchase limits, billing 
cycle limits, budget limits, organization account code limits, 

25 product type limits. 

4. A system as recited in claim 2, wherein said credit card 
system subjects a purchase to the limits at a time of the 
purchase. 

5. A system as recited in claim 1, wherein said credit card 
30 system automatically reconciles the transactions. 

6. A system as recited in claim 5, wherein reconciliation 
searches for an obligation created in the financial manage- 
ment system at a time of a purchase. 

7. A system as recited in claim 5, wherein reconciliation 
35 searches for an obligation created in the financial manage- 
ment system prior to a purchase. 

8. A system as recited in claim 5, wherein reconciliation 
updates budget, planning, project and ledger entries of the 
financial management system of the organization. 

40 9. An integration system associable with a credit card 
issuing system issuing credit cards to multiple users of an 
organization with each of the cards having issuer limits and 
said integration system comprising: 
45 a financial management system providing control and 
accounting for financial transactions, and providing 
financial system limits; and 
a credit card management system associated with the 
financial management system and the credit card issu- 
50 ing system, and providing spending control and 
accounting for credit card transactions with the credit 
card issuer within the financial management system 
using the financial system limits imposed by the orga- 
nization and where said credit card system authorizes 
5S immediate payment to the credit card issuer of pre- 
obligated transactions. 
10. An integration system associable with a credit card 
issuing system issuing credit cards to multiple users of an 
organization with each of the cards having issuer limits and 
60 said integration system comprising: 

a financial management system providing spending con- 
trol and accounting for financial transactions, and pro- 
viding financial system limits; and 
a credit card management system associated with the 
65 financial management system and the credit card issu- 
ing system, and providing spending control and 
accounting for credit card transactions with the credit 
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card issuer within the financial management system 
using the financial system limits imposed by the orga- 
nization and where said credit card system authorizes 
immediate payment to the credit card issuer of pur- 
chases approved by the credit card system at the time 
of purchase. 

11. A system as recited in claim 1, wherein said credit card 
system validates credit card information on credit card 
statements. 

12. An integration system associable with a credit card 
issuing system issuing credit cards to multiple users of an 
organization with each of the cards having issuer limits and 
said integration system comprising: 

a financial management system providing control and 
accounting for financial transactions within an organi- 
zation; and 

a credit card management system associated with the 
financial management system and the credit card issu- 
ing system, and providing spending control and 
accounting, at a time of purchase, for credit card 
transactions of the financial management system of the 
organization using the financial system limits imposed 
by the organization and comprising checking the trans- 
actions against the organization financial system limits 
including single purchase limits, billing cycle limits, 
budget limits, organization account code limits, prod- 
uct type limits, validating credit card information on 
credit card statements, automatically reconciling the 
transactions by searching for an obligation created in 
the financial management system at a time of a 
purchase, updating budget, planning, project and ledger 
entries of the financial management system, authoriz- 
ing immediate payment of purchases approved by the 
credit card system at the time of purchase and setting up 
disputes for unapproved purchases. 

13. A method of processing credit card transactions, 
comprising: 

receiving a credit card transaction from a card issuer; and 
automatically reconciling the transaction within a finan- 
cial management system of an organization against a 
financial system record showing an intent to purchase. 

14. A method, comprising: 

receiving a credit card transaction from a card issuer for 
a vendor at a time of purchase to which issuer limits are 
applied by the issuer of a credit card; and 

providing, by an organization separate from the issuer and 
at a time of transaction processing, control and 
accounting for the credit card transaction within a 
financial management system of an organization to 
which organization limits are applied and thereby 
approving/denying the transaction. 

15. A method of processing credit card transactions, 
comprising: 

receiving a credit card transaction from a vendor and 
subjecting the transaction to card issuer limits by an 
issuer of a credit card; and 

subjecting the transaction, by an organization separate 
from the issuer and at a time of transaction processing, 
to financial system limits of the organization and 
thereby approving/denying transaction. 

16. A method as recited in claim 15, wherein said financial 
system limits comprise one of single purchase limits, billing 
cycle limits, group limits, budget limits, planning limits, 
funds availability limits, organization account code limits, 
product type limits. 

17. A method as recited in claim 15, wherein said sub- 
jecting converts the transaction into an obligation when the 
limits are satisfied. 
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18. A method as recited in claim 15, wherein an intent to 
perform the transaction is captured by the financial man- 
agement system before the transaction occurs. 

19. A credit card system, comprising: 

a credit card issuer system providing for approval of 
credit card transactions using issuer limits; and 

a financial management system of an organization sepa- 
rate from and communicating with said issuer, accept- 
ing the credit card transactions and providing, at a time 
of transaction processing, approval of the transactions 
using organization limits and thereby approving/ 
denying the transaction. 

20. A system as recited in claim 19, wherein said man- 
agement system provides pre-purchase approval of the trans- 
actions. 

21. A system as recited in claim 19, wherein said man- 
agement system authorizes immediate payments prior to 
approval, creates a discount transaction for the issuer in 
proportion to the payment and updates a discount income 
organization account in the financial management system. 

22. A system as recited in claim 19, wherein said man- 
agement system allows initiation and tracking of disputes 
with respect to the credit card transactions. 

23. A credit card system, comprising: 
a credit card issuer; and 

a financial management system of an organization com- 
municating with said issuer, accepting credit card trans- 
actions and providing automated handling of disputes 
over credit card purchases including tracking each of 
the disputes through resolution. 

24. A system, comprising: 

a packet-switched communication system; 

a credit card issuing system issuing credit cards to mul- 
tiple users of an organization each card having issuer 
limits and coupled to said communication system; 

an organization financial management system coupled to 
said communication system, storing credit card infor- 
mation related to financial system organization account 
codes and accounting for financial transactions of mul- 
tiple users comprising limits imposed by the organiza- 
tion with the transactions intermingling within the 
system; and 

a user terminal coupled to said communication system 
and allowing a user access to the credit card informa- 
tion of the multiple users, 

25. A system as recited in claim 24, wherein the system 
organization account codes relate to user credit card budgets. 

26. A computer readable storage medium including a 
process receiving a credit card transaction from a card issuer 
and automatically reconciling the transaction within a finan- 
cial management system of an organization against a finan- 
cial system record showing an intent to purchase. 

27. An integration system associable with a credit card 
issuing system issuing credit cards to multiple users of an 
organization with each of the cards having and imposing 
issuer limits and said integration system comprising: 

a financial management system of an organization pro- 
viding control and accounting for financial transactions 
of organization employees and providing financial sys- 
tem limits, and comprising a credit card system of the 
organization separate from the financial management 
system and providing, at a time of transaction 
processing, spending control and accounting for credit 
card transactions of the employees within the financial 
management system using the financial system limits 
imposed by the organization and thereby approving/ 
denying the transaction. 
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28. A system as recited in claim 1, wherein the limits 
comprise non-financial limits. 

29. A system as recited in claim 28, wherein the non- 
financial limits comprise one of vendor restrictions, product 
restrictions, service restrictions and time period restrictions. S 

30. A financial system of an organization coupleable to a 
credit card system issuing credit cards to multiple users in an 
organization and the credit card system controlling spending 
by the users responsive to issuer limits set via the credit card 



20 



system and said financial system of the organization com- 
prising a financial management system, separate from the 
credit card system, providing control and accounting for 
financial transactions by the users and approving spending 
via the credit cards, at a time of the financial transactions, 
through the credit card system responsive to financial system 
limits set by the organization. 
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ABSTRACT 



A system for managing requests for services from vendors 
including a database having contract information for 
vendors, entitlement information for users and requests for 
services. The requests are compared with the entitlement 
information for the requesting user and the contract infor- 
mation for the vendor that supplies the information to 
determine if the request is approved. If the request is 
approved, the system generates an associated billing item in 
the database for the request and the approved request is 
transmitted to the vendor. The vendor sends an invoice of 
charges associated with the approved requests which is 
compared with the associated billing items for the approved 
requests. Additionally, a method for managing user requests 
for services from vendors is provided including providing a 
database for storing contract information for vendors, 
entitlement information for users and requests for services 
from a vendor. The method includes generating a request for 
services from a vendor and transmitting the request to the 
database. The method compares the request for services to 
entitlement information for the user and contract informa- 
tion for the vendor, and generates an approved request and 
an associated billing item in the database. The method 
includes receiving from the vendor an invoice of charges 
associated with the approved request and comparing the 
invoice with the associated billing item for the approved 
request. 

9 Claims, 8 Drawing Sheets 
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METHOD AND SYSTEM FOR charge rates that are related to the number of users within the 

STANDARDIZING AND RECONCILING financial service client. Often the rate structures can be a flat 

INVOICES FROM VENDORS monthly fee for a user. Alternatively, a flat fee for the 

company may be charged (in which case the present system 

CROSS REFERENCE TO RELATED 5 ^ US eful for providing an automated method of posting 

APPLICATIONS charge -backs to the department or user), or a fee per request 

The present application claims the benefit of U.S. Provi- or for line usa g e iime mav be used - Finally, tiered pricing 

sional Application Ser. No. 60/040,909, filed Apr. 2, 1997 by schedules and volume or other discounts need to be tracked, 

the inventor herein. In many of the large financial institutions, a typical 

10 vendor's printed invoice may be an inch thick and contain 
thousands of line items. Since services and entitlements may 
The present invention relates to a system and method for be charged based on a monthly fee, for example, often when 
tracking products and services usage; and more particularly additions or deletions of users are made to an account, such 
to a system and method of storing information about vendor changes appear on the following month invoice as a series 
contracts, user entitlements to the vendor products and 15 of debits and credits. For example, if a bank deletes an 
services and requests for a product or services, as well as entitlement in the middle of March for one user, the monthly 
tracking changes in a database. The system and method invoice for that service will typically include a charge for 
allows for comparing costs charged for the requests and one months usage by the user. The remaining days in March 
actual usage against vendor invoices. The system and not actually used are then credited on the April invoice, 
method can handle different vendor billing methods such as 20 Because of the extensive amount of data required in 
flat fees, a fee per request, monthly tiered fees and various tracking individual user entitlements and reviewing the 
methods of applying a discount. The system and method can hundreds of monthly invoices, typically a financial service 
also track changes in user entitlements to different vendor company can only conduct a summary review of the 
products and services. invoices. In general, if an invoice remained fairly constant 
A preferred embodiment shows the invention being 25 on a month-to-month basis, it is generally paid without any 
applied to the financial services industry. Financial institu- further detailed reconcilement. For an invoice that is more 
tions such as major banks, brokerage houses, insurance than marginally different from the month-to-month average, 
companies and the like rely on information provided by a firm can spend up to three to four weeks per month 
specialized financial and market data service providers. reconciling and charging back these invoices. 
Many financial institutions may subscribe to well over 100 In addition to invoice reconcilement and billing, there is 
different national and international news and price feed a need within the financial institutions for managing the 
information services. A typical large bank may spend an related functions of procurement and contract management 
average of $12 M annually on such services. for the market data services; hardware and software inven- 
Within the large financial institutions, individual users, 35 tory control, and help desk support; managing moves and 
such as analysts, traders and the like will be entitled to have changes among users and among user entitlements; and 
access to particular market data products and services, managing internal departmental charge backs where the fees 
generally determined by their department or division, as is for the market data services are apportioned to the appro- 
appropriate for that user. Typically, a centralized manage- priate department or user. In the current state of affairs for 
ment department, typically a help desk function, within the 4Q typical financial institutions, disparate manual and auto- 
company will assign the access rights for a particular user to mated systems are used for one or another of these various 
a particular product or service. A user's unique set of functions and often cause duplicate processing and data 
available market data services, or entitlements needs to be entry throughout the various responsible areas within the 
managed and tracked. These entitlements, for example, can financial institution. 

change or remain with a user if that user changes 45 What is desired is a system and method that can track 

departments, or moves its physical desk. vendors and contract related data, including costs for every 

Typically, physical moves within a company or between type of service provided by the vendors. The system should 

departments are frequent, especially at banks or other finan- maintain complete information on market data service 

cial institutions and there is a higher- than-average turnover contracts, with on-line update of service terms and usage, 

ratio in the financial services industry. For example, in many 50 The system preferably tracks vendors, contracts, products, 

banks, two-year training programs for analysts start every services, various vendor pricing methodologies, delivery 

summer and service entitlements must frequently be added and third-party billing information. 

or deleted for the new users to keep up with current staffing. It is also desirable for the system to process and reconcile 

Management of the resources involved in accessing invoices from the vendors. For example, the system should 

on-line information from vendors can raise additional com- 55 reconcile vendor invoices against individual usage data. It 

plications. Certain services may require specialized hard- would be most desirable for the system to receive electronic 

ware or licensed software to be used in accessing the invoices for direct import into the system from the market 

information. Additionally, certain dedicated modems or information service vendors. The system then automatically 

phone lines may have to be provided. When a physical move calculates costs based on an inventory of actual requests for 

of a user is planned, decisions on whether to move the 60 information, and calculates unit costs for services based on 

hardware and other infrastructure needs to be made. If a new the various vendor pricing methodologies. The system 

user occupying the seat will require the same resources as should automate the reconciliation of charges against usage 

were there, then only the changes in the user name are data and provide appropriate charge back reports, 

needed. Often, however, physical equipment or software It is desired to provide an internal charge back processing 

will have to be moved. 65 function which can allocate monthly market data costs back 

The many market data and information services vendors to the financial service institution user or department. Unit 

typically invoice for their services on a monthly basis and costs for all services are calculated at various levels and 
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pricing methodologies and include an appropriate allocation 
for direct usage charges, shared account level charges and 
company site license type allocations. In the past, this 
function has been a manually intensive, imprecise and 
incomplete process. 5 

The system desirably contains a real-time inventory of 
locations, hardware, software and entitlements for users or 
employees. Historical usage information should also be 
maintained by the system to verify new charges and credits 
with the vendors. 10 

The system should manage help desk functions, such as 
moving a user or changing a user's entidements. Preferably, 
the system can create "tickets" for repairs and work orders 
covering equipment, market data services, and general hard- 
ware or software help. The system should desirably also 15 
track calls to a help desk and record completion of help desk 
requests. 

The system should also have the capability of planning 
and implementing both small and large-scale moves of 2Q 
multiple employees or users, entitlements and equipment 
from one seat to another. Employees, entitlement and equip- 
ment should be able to be moved independently from one 
another. Once a particular move is planned, the system 
generates and tracks the individual "tickets" or work orders 25 
which are needed to perform the move. Work orders are then 
routed automatically to the appropriate department, vendors 
and contractors who will be performing the individual tasks. 

The system and method of the present invention satisfies 
all of the above needs and advantageously provides a 30 
complete integrated solution to meet the disparate require- 
ments of the various departments that manage, use and 
implement market information and data services. It elimi- 
nates duplicate efforts and the intensive manual processing 
of invoices, move processing and work order tracking. The 35 
system and method is able to monitor and prevent duplicate 
services from being received at certain seats where multiple 
vendors are providing the same data to the user. The system 
and method is able to reconcile and uncover discrepancies 
between line item totals and invoice amounts relative to the 40 
entitlements of individual users. The system and method of 
the present invention can enable a financial institution to 
perform a complete line -by-line audit of every vendor 
invoice which will allow reconciliation of every line item 
and every mid- month credit and charge. 45 

SUMMARY OF THE INVENTION 

The present invention relates generally to a system and 
method for reconciling vendor invoices for products and 
services with actual usage by individual users within a 50 
company. More particularly, the present invention is a com- 
puterized system and method for receiving invoices from 
vendors and tracking the amounts in the invoices against a 
database containing information about the vendor service 
contracts, user entitlements to that service, and actual usage 55 
of the service. The system also includes functions for 
automated tracking and inputting or changing user 
information, vendor service contract changes, and help desk 
requests related to the hardware or software used to acquire 
the data from the vendor products and services. 60 

The system of the invention processes accounts payable in 
the back office of, for example, the trading floor of a bank 
or other financial institution. In a particular embodiment of 
the invention, various traders or other users order on-line 
market information services, magazines and other informa- 65 
tion for the purposes of carrying out their job and analyzing 
the market. Determinations are made whether those products 
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and services are authorized to be purchased, and then they 
are entered irjto the system, processed and paid. The system 
receives invoices from vendors in electronic form, and 
facilitates reconciling and processing so that the accounts 
payable department can pay the invoices. 

The system of the invention is a fully integrated expense 
control system and is capable of doing a profit and loss 
analysis based on the vendor products and services charged 
for, and the revenue generated by the users requiring those 
services. The system tracks inventory, reconciles invoices 
and is capable of educating the business people by gener- 
ating various reports. 

The system and method of the invention is capable of 
providing a return on investment analysis as well. For 
example, many of the services from market information 
providers include a one-month free trial. The system would 
enable the manager running the department interested in the 
trial to determine if adding the trial service as an entitlement 
to the department users would enhance the performance of 
those receiving that particular service, and thus the manager 
can evaluate whether the service should be purchased 
beyond the trial month. Additionally, if different vendors 
provide similar services, an analysis can be made of which 
one costs less. The system provides profit and loss account- 
ability allowing business managers the opportunity to deter- 
mine the actual value of vendor products and services. 

In accordance with the invention, a system for managing 
product and service usage from vendors is provided. The 
system includes a database having contract information for 
vendors, entitlement information for users and requests for 
a product or service from a vendor made by a user. The 
requests for products and services from a vendor are gen- 
erated by the user of the system. The requests are compared 
with the entitlement information for the requesting user and 
the contract information for the vendor that supplies the 
product or service to determine if the request is approved. If 
the request is approved, the system generates an associated 
billing item in the database for the request. The approved 
request is transmittable to the vendor. The system receives, 
from the vendor, an invoice of charges associated with the 
approved requests, and compares the invoice with the asso- 
ciated billing items for the approved requests. 

Additionally, in accordance with the invention, a system 
for managing user requests for products and services from 
vendors is provided. The system includes a database for 
storing contract information for vendors, entitlement infor- 
mation for users and requests for products and services from 
a vendor. The system includes input/output means operable 
by a user for generating a request for products and services 
from a vendor and transmitting the request to the database. 
The request for products or services is compared to the 
entitlement information for the requesting user and the 
contract information for the vendor to determine if the 
request is approved. The system generates a billing item 
associated with approved requests and transmits the billing 
item to the database. The approved request is transmittable 
to the vendor. The system receives from the vendor an 
invoice of charges associated with the approved request and 
compares the invoice with the associated billing item for the 
approved request. 

In accordance with the invention, a method for managing 
requests for products and services from vendors is provided. 
The method includes providing a database which stores 
contract information for vendors, entitlement information 
for users and requests for a product or service from a vendor. 
The method includes generating, by a user, a request for a 
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product or service from a vendor, and comparing the request 
with the entitlement information for the user and the contract 
information for the vendor to determine if the request is 
approved. Approved requests are transmittable to the vendor. 
The method includes generating an associated billing item in 5 
the database for approved requests. The method includes 
receiving from the vendor an invoice of charges associated 
with approved requests, and comparing the invoice with the 
associated billing item for the approved request. 

Additionally, in accordance with the invention, a method 10 
for managing user requests for products and services from 
vendors is provided. The method includes providing a 
database for storing contract information for vendors, 
entitlement information for users and requests for a product 
or service from a vendor. The method also includes 15 
generating, by a user, a request for a product or service from 
a vendor and transmitting the request to the database. The 
method compares the request for a product or service to 
entitlement information for the user and contract informa- 
tion for the vendor, and generates an approved request. The 20 
system generates a billing item associated with approved 
requests and transmits the billing item to the database. The 
approved request is transmittable to the vendor. The method 
includes receiving from the vendor an invoice of charges 
associated with the approved request and comparing the 25 
invoice with the associated billing item for the approved 
request. 

An object of the invention is to provide on-line product 
and service request management between end users and 
vendors. 30 

It is a further object to provide automation of invoice 
reconciliation for quantity and dollar amount of products 
and services used, against a database containing costs and 
other information for the products and services. 35 

Still another object of the invention is to provide auto- 
mation of the invoice approval processes by accounts pay- 
able. 

Yet another object of the invention is to provide end user 
charge notification by an on-line network system. 40 

Still another object of the invention is to provide auto- 
mated accrual and financial management tools. 

Still other objects and advantages of the invention will, in 
part, be obvious and will, in part, be apparent from the 
specification. 45 

The invention, accordingly, comprises the several steps 
and the relation of one or more of such steps with respect to 
each of the others, and the system embodying features of 
construction, combinations of elements and arrangement of 
parts which are adapted to affect such steps, all as exempli- 50 
fled in the following detailed disclosure, and the scope of the 
invention will be indicated in the claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a full understanding of the invention, reference is had 
to the following description taken in connection with the 
accompanying drawings in which: 

FIG. 1 is a schematic representation of an on-line service 
management system in accordance with the present inven- 60 
tion; 

FIG. 2 is a schematic representation of an on-line service 
request management system in accordance with the present 
invention; 

FIG. 3 is a schematic representation of an automated 65 
invoice processing and payment authorization system in 
accordance with the present invention; 
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FIG. 4 is a schematic representation of a monthly financial 
cycle accrual and allocation/direct charge system in accor- 
dance with the present invention; 

FIG. 5 is a flowchart showing the steps for adding a new 
desk in accordance with the system and method of the 
present invention; 

FIG. 6 is a flowchart showing the steps for adding a new 
service in accordance with the system and method of the 
present invention; 

FIG. 7 is a flowchart showing the steps for deleting a 
service from a desk in accordance with the system and 
method of the present invention; 

FIG. 8 is a flowchart showing the steps for entering an 
invoice in accordance with the system and method of the 
present invention; and 

FIG. 9 is a representation showing the steps for paying an 
invoice in accordance with the system and method of the 
present invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

The automated system and method of the invention 
allows, for example, a financial institution to manage a 
complex array of market data services effectively and effi- 
ciently. The system and method allows tracking of and 
maintaining of the details for the market data services and 
equipment contracts with the various market data service 
providers or vendors. The system allows a company, such as 
a financial institution or bank, to track and maintain vendor 
services for every user in the company. The system and 
method allows a manager to plan and execute user moves 
from seat to seat and the help -desk manager can move all or 
selected services and equipment for employees. 

A database provided by the system is updated automati- 
cally when a move is completed. The system can create and 
track help desk work tickets for all help desk requests, 
including changes to market data service usage. The market 
data services database is updated automatically when the 
ticket is closed. 

The system allows for review of service usage and can 
identify duplications, track monthly changes and costs by 
user, and perform various functions useful for business and 
planning. For example, the system of the invention can 
reconcile monthly vendor invoices against the market data 
service database of user requests. 

FIG. 1 shows and on-line market data service manage- 
ment system in accordance with the invention. User infor- 
mation is generally tracked by a seat location. For a user, 
different entitlements to various market data service provid- 
ers can be made. The entitlements may be grouped for 
particular departments and a user's entitlements may be 
based on a profile for that department. The information 
about a user profile 20 is entered into a database 24. 
Database 24 constitutes the central repository for all infor- 
mation for managing on-line market data service requests 
and associated functions. 

Database 24 also includes vendor contract information 28 
which may generally include the time frame or period for 
which the contract is valid, and the cost and quantity of 
services available under the contract. Database 24 also 
includes additional information to be described below. 

Requests for on-line market data are made by an end user 
32. End user 32 is identified by a seat location which should 
match the seat location for that user's entitlement informa- 
tion 20 as entered in database 24. End user 32 will make an 
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on-line market data service request 36, which is judged 
against business criteria in an expert system 40, which relies 
on information from database 24 as described below with 
reference to FIG. 2. 

In accordance with the comparison by expert system 40 5 
against business criteria, on-line service request 36 may be 
rejected 44 and notification to end user 32 provided. 
Generally, however, end user 32 will make an on-line 
service request 36 for a market data service to which end 
user 32 is entitled, as reflected in end user's entitlement 10 
information 20 in database 24. Therefore, on-line service 
request will typically be accepted 48 and the system will 
prepare a formatted request for information 52 which will 
include vendor information, service information, optionally 
an expense code, cost, and contract billing start date and 15 
period, all of which information can be retrieved from 
database 24 and vendor contract records 28. 

It is important to recognize that requests for information 
36 in the context of the on-line market data service man- 
agement system in accordance with the invention, can be 20 
actual user requests for market data information and can 
additionally be help desk requests for adding a user, deleting 
a user, or adding or deleting a service for any given user, all 
as described further below. 

25 

The formatted request for information 52 is transmitted to 
vendor 56 and vendor 56 will transmit a confirmation back 
to the system 60, thus assuring that an accurate record of the 
request has been received by vendor 56 and database 24. 
Once the formatted request for information 52 is confirmed 3Q 
60 by vendor 56, database 24 is updated 64 with information 
about the request. Therefore, database 24 also includes 
information about actual requests for market data informa- 
tion as well as accurate information for user 32. 

Information in database 24 can be used by business 35 
managers and planners to forecast charges for market data 
services and charging back actual costs of those services to 
the departments or even individual users. In addition, the 
information in database 24 can be used to reconcile invoices 
from vendors 56. Vendors 56 prepare a invoice 68 which will 40 
include certain standardized fields such as account number 
and charges. Standardized invoice 68 is transmitted to the 
system for invoice reconciliation, payment authorization, 
accrual of charges, and end user charge notification, all 
indicated at 72. Invoice reconciliation 72 collects reconcili- 45 
ation data 76 from database 24. If invoice reconciliation 72 
does not match information in database 24 with invoice 68, 
the invoice is rejected 80 and sent back to vendor 56. If 
invoice reconciliation matches information from database 
24 with invoice 68, invoice 68 is accepted 82 and the system 50 
sends the information to a payment authorization function 
84 which prepares the appropriate routing slips and sends 
the correct forms to accounts payable 88. Information from 
payment authorization 84 and from accounts payable 88 is 
transmitted to the accruals and general ledger function 92 55 
which, along with receiving additional information from 
database 24, provides the financial cycle information for the 
month and prepares monthly allocations and direct charges 
back 96 to departments. The monthly allocation and direct 
charges 96 are transmitted to end user 32 and the tracking 60 
and management of on-line market data is complete. 

FIG. 2 shows in greater detail the on-line service request 
function of the system in accordance with the invention. As 
described above, end user 32 makes a market data informa- 
tion request 36 and the market data information request 36 65 
is compared with business criteria in an expert system 
generally indicated at 40. Expert system 40 includes a 



preliminary review 100 which checks the parameters 104 of 
information about the user in database 24 to generate an 
approval 108, after which a formatted request for informa- 
tion 52 is prepared. 

Preliminary review 100 may automatically reject 112 the 
request 36 for any number of reasons, such as end user 32 
not being entitled to the requested service. In the case of a 
rejection 112, end user 32 is notified. 

Preliminary review 100 may marginally approve or reject 
request 36 and provide such information to a business 
manager approval function 116 which can reject the request 
120, notifying user 32, or accept 124 request 36 and prepare 
the formatted request for information 52 depending on the 
particular business needs for the request. 

As discussed above, formatted request for information 52 
is transmitted to vendor 56 for an on-line confirmation 60, 
and when received, updates 128 database 24. 

FIG. 3 shows in greater detail the automated invoice 
processing and payment authorization function of the system 
in accordance with the invention. Vendor 56 receives request 
for information (not shown) and prepares a standardized 
invoice 68 which includes certain necessary fields such as 
the account number, cost, vendor, service and the dates used. 
The invoice is sent to the system and a reformatted invoice 
132 is generated. In order to provide a snapshot of the 
account information, an arbitrary cut-off date 136, for 
example, the 15th of the month in the example is used. The 
standardized reformatted invoice 132 is sent to the auto- 
mated reconciliation function 72. 

If standardized reformatting 132 does not find the neces- 
sary information, an exception 140 is made and vendor 56 
notified. 

Similarly, automated reconciliation 72 may reject an 
invoice and generate an exception 144 and vendor 56 so 
notified. Automated reconciliation 72 uses information from 
database 24 to reconcile the invoices. Automated reconcili- 
ation 72 also updates database 24 and prepares a valid 
invoice 152 for automated sign-off 156. Automated sign-off 
156 prepares an internal bill, checks the signatures and 
compliance and forwards the information to accounts pay- 
able 88 which also updates database 24. 

FIG. 4 shows the monthly financial cycle accruals and 
allocation of the direct charge function of the invention. An 
automated accrual function 92 can get information from 
database 24 in order to prepare a monthly expense report 
160. Since database 24 also contains current information on 
reconciled invoices, the amount of reconciled invoices 164 
can be subtracted from the monthly expenses to determine 
the accruals for the month 168. Accruals 168 can be reported 
by vendor, or account number or expense code as necessary. 
Information on the monthly accrual 168 can then be sent to 
the general ledger function 172 and expenses forecasted. 
Database 24 can also provide charge back and allocation 
information to the end users. Information from database 24 
can be extracted and reported 176 and these reports sent as 
a notification to the end user 96 which may include alloca- 
tions 180 or direct charges 184 for that user. 

As described above, a user of the system in accordance 
with the invention is assigned a seat number which generally 
corresponds to a physical desk. When a new user is added to 
the system, a request to the help desk is made for adding a 
new desk. The help desk adds a new desk in accordance with 
the method shown in FIG. 5. The new desk 501 is generated. 
It is determined whether a new expense code 502 is needed 
for this desk. If not, it is determined whether this new desk 
is physically at a new location 503. If, on the other hand, a 
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new expense code 502 is generated, an expense code is 
added 504 to the master tables and the new location is added 
505. Similarly, if it is not a new expense code 502 but it is 
a new location 503, the new location is added 505 to master 
tables. Then, all required fields are updated 506 to the master 5 
tables. Also, if new location 503 is not required, then 
required fields are updated 506 in the master tables for the 
desk. 

New services can be added to an existing seat or desk. The 
method for adding a new service is shown in FIG, 6. For any 10 
new market data service vendor, for which ao entitlement is 
to be given to a new desk, a ticket 601 is filled out for the 
help desk which will include information such as vendor 
name and account number, service name, user name desk at 
location, and the like. The service i.d. and desk i.d. codes are 15 
checked to see if they currently exist in the data base 602 and 
if not, new unique service or desk Ld.'s are created 603. If 
the service codes exist in the master data files, the current 
i.d.s are used 604. In either case the master data tables are 
updated with the new information 605 and the new record is 20 
added to the database 606. 

Likewise, services may be deleted from a desk where a 
user's entitlement no longer includes that service. The 
method is shown in FIG. 7. A delete order 701 is filled out 
and transmitted to the help desk and the desk is removed by 25 
modifying the master table 702 by the help desk. 

Invoices from vendors are entered into the system by the 
method shown in FIG. 8. Anew invoice 801 is received and 
it is determined whether it is from a new vendor 802. If it is 3Q 
not, it is determined whether it is a new contract 803. On the 
other hand, if it is a new vendor 802, then the new vendor 
name is added 804 to the vendor data in the master tables and 
new contract i.d. information is also added 805. Likewise, if 
it is a new contract 803, new contract information is added 
805. 35 

However, if it is not a new vendor 802 and it is not from 
a new contract 803, it is determined whether a new account 
is being invoiced 806. If it is a new account 806, the new 
account information is added 807 to the master table and the 40 
invoice is entered 808 into the database. Likewise, if it is not 
a new account, the invoice can also be added 808 directly to 
the database. 

Once the invoice is in the system, the invoice payment 
process can occur as shown in FIG. 9. The system looks up 45 
the total service count 901 and quantity 902 from the stored 
data information in the database. The quantity is reconciled 
903 by comparing the total service count 901 with total 
service quantity 902. If the reconciliation 903 is off, all desks 
are checked for outstanding service i.d. errors 904. If, on the 50 
other hand, the reconciliation is within tolerances, the 
amount is reconciled 905 by comparing the total amount on 
the invoice 906 and the amount 907 from the database. 
Again, if the amount reconciled is off, data is sent to the 
accrual data base and the service i.d. is updated 908 or, if the 55 
reconciled amount 905 is correct, the system indicates that 
it is okay to pay 909. 

The system and method is preferably implemented by 
software on a computer and preferably takes the form of a 
graphic user interface application. Managers and users may 60 
have different functions available to them, depending on the 
configuration of the system. A "help desk" function is 
available to access the help desk ticket entry and move 
functions described above, and allows a manager to assign 
market data services to specific users. A market data function 65 
allows users or managers to access and request market data 
services. 
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The system of the invention in the preferred embodiment 
helps a financial institution manage market data services. 
The help desk has access to update the market data service 
master tables, and can define vendor products and services, 
track and maintain service usage, review service usage, 
import and reconcile vendor invoices, process data and run 
reports. 

Different vendor products and services can have different 
charge back types, which determine how the cost of a service 
will be billed to users. Service types generally come in two 
predefined types, for example, and additional service types 
can be defined as needed. The pre-defined service types are 
individual services, that is the seat to which the service is 
assigned pays the full cost of use of that service. The other 
type of service is a shared account in which the total cost for 
all units of the service delivered to an account is shared 
among all seats receiving any service from that account. For 
example, if five units of the service are delivered to an 
account, and ten seats receive a service through that account, 
the cost of the five units is divided evenly among the ten 
seats. 

A billing type is used to indicate how a service is billed 
by the vendor. Typical billing types include third-party 
billing in which a service is billed by the vendor originating 
the service (the third-party vendor) rather than the delivering 
vendor. Delivering vendor billing is where services are 
billed by the vendor delivering the service regardless of 
where the service originates. 

Market information products and services are purchased 
from vendors. The vendor's product or service is listed in the 
vendor master tables. Vendor master tables include infor- 
mation for the vendor, vendor contacts, vendor products and 
vendor services. Basic name and address information for the 
market data information vendor can appear on a vendor data 
screen. Vendor products are defined on a products screen. 
Some vendors offer clearly defined products, such as Teler- 
ate's "digital fee." Other vendors may offer only a single 
suite of services with no product name, or only individual 
services. Market data services received from the vendor are 
separately defined on a vendor services screen. Service 
codes for associated charges, such as site charges, that are 
billed monthly may be indicated in the vendor services 
screen. 

Additionally a vendor service may include an indication 
if the service pricing is tiered. Tiered pricing is used to 
handle a number of pricing situations as described below. 
Additionally, a discount rate offer by the vendor, whether a 
discount applies, may be indicated. Finally, if the services 
are charged through a third-party vendor rather than the 
delivering vendor, another indication can be made. 

Tiered pricing is used for certain pricing situations. Clas- 
sic tiered pricing, such as when 1-4 units cost $100 per unit 
and 5-9 units cost $80 per unit and so on; first unit pricing, 
as when the first unit cost $50 and all additional units cost 
$10; tiered percentage discounts as when 1-4 units are not 
discounted and additional units receive a 10% discount and 
so on (mathematically equivalent to classic tiered pricing); 
and site fees. Preferably site fees can be handled in a 
different manner, but it is possible to include the site fee as 
part of the first unit cost. 

Service usage is tracked in a service usage and invoice 
screen. On this screen a user can input account, contact and 
invoice data and can review data from vendors. When the 
user accesses the service usage and invoices screen, typi- 
cally they will select a vendor name from a vendor name 
drop down box. Vendors can be added in the vendor data 
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screen by the help desk. The user can enter or edit the 
number of units which are purchased in a month under the 
site license contract for the service. To add or edit other 
information, the user can go to other screens. 

In most cases, one account number is associated with one 5 
account. If the contract covers five units of a service, the cost 
of those units is allocated among all seats that receive one or 
more individual services through that account. 

The invoices function permits a manager to enter vendor 
invoices for reconciliation against market data information 10 
service provider invoices. The manager can view or edit 
invoices that have been imported electronically. Different 
vendors provide a different set of data fields in their 
invoices. However, it is preferable that at least certain data 
fields are in common. Typically the invoice records will 
include fields for vendor service, vendor service code, a start 
and end date of billing for this service, quantity of service 
billed, unit cost, charged amount, discount percent, discount 
amount, tax rate percent, tax amount and final cost. Once the 
invoices are in the system, the manager can access the 
reconcile function to go directly to the reconcile invoices 20 
screen. The currently selected invoice will be entered on that 
screen. 

The system allows managers and the help desk to process 
the data and generate report files or compute cost per seat 
amounts and the allocation of vendor service cost to indi- 
vidual seats. For services defined as individual, non- 
licensed, and non-tiered priced, the process is simple. The 
unit cost of this service, after discounts and taxes, is charged 
to the seats receiving this service. For other services, the cost 
per seat depends on the number of seats receiving this 
service. This is true for licensed tiered price and shared 
account services. Computing these costs for the entire site 
has typically been a time consuming process. For that reason 
most marketing data service management system reports do 
not recompute cost per seat when they are run. Instead, they 
rely on figures generated by the reporting and history 
functions. 

The help desk portion of the market data service man- 
agement system allows a user to effect moves of a user or 4Q 
equivalent and services from one seat to another, or to add 
or delete services, equipment and network I.D. from a 
particular seat. 

Accordingly, the present invention provides a method and 
system for tracking user requests for services and invoices 45 
from vendors in a comprehensive and efficient manner. The 
system and method are adaptable and useable with many 
different programs and activities. 

It will thus be seen that the objects set forth above, among 
those made apparent from the preceding description, are 50 
efficiently attained and, since certain changes may be made 
in carrying out the above method and in the constructions set 
forth without departing from the scope of the invention. It is 
intended that all matter contained in the above description 
and shown in the accompanying drawings shall be inter- 55 
preted in an illustrative sense and not in a limiting sense. 

It is also to be understood that the following claims are 
intended to cover all of the generic and specific features of 
the invention herein described and all statements of this 
scope of the invention which, as a matter of language, might 60 
be said to fall there between. 

I claim: 

1. A computer implemented system for managing a plu- 
rality of user requests for services provided by vendors, 
comprising: 65 

a database storing contract information for vendors, 
entitlement information for users and a plurality of 



billing items associated with user requests for services 
provided by a vendor; 

means for generating a user request for services provided 
by a vendor, and for comparing said user request with 
said entitlement information for said user and said 
contract information for said vendor to determine if 
said user request is an approved request; 

means for including a billing item associated with said 
approved request in said database, and means for 
transmitting said approved request to said vendor; 

means for receiving from said vendor an invoice of 
charges for services associated with a plurality of 
approved requests including said approved request, and 
for comparing said invoice with said plurality of billing 
items including said billing item; and 

means for allocating in accordance with said billing item 
a portion of said invoice to said user generating said 
approved request; whereby users receiving services 
from said vendor are charged an appropriate portion of 
said invoice in accordance with those services said 
users received from said vendor. 

2. The computer implemented system of claim 1 wherein 
said invoice of charges includes a monthly fee per user. 

3. A computer implemented system for managing a plu- 
rality of user requests for services provided by vendors, 
comprising: 

a database for storing contract information for vendors, 
entitlement information for users and a plurality of 
billing items associated with user requests for services 
provided by a vendor; 

input/output means operable by a user for generating a 
user request for services provided by a vendor; 

means for comparing said user request for services to 
entitlement information for said user and contract infor- 
mation for said vendor, and generating an approved 
request in response thereto; 

means for generating a billing item associated with said 
approved request and transmitting said billing item to 
said database; 

means for transmitting said approved request to said 
vendor; 

means for receiving from said vendor an invoice of 
charges for services associated with a plurality of 
approved requests including said approved request and 
comparing said invoice with said plurality of billing 
items including said billing item; and 

means for allocating in accordance with said billing item 
a portion of said invoice to said user generating said 
approved request; whereby users receiving services 
from said vendor are charged an appropriate portion of 
said invoice in accordance with those services said 
users received from said vendor. 

4. The computer implemented system of claim 3 wherein 
said invoice of charges includes a monthly fee per user. 

5. A computer implemented method for managing a 
plurality of user requests for services provided by vendors, 
comprising: 

providing a database storing contract information for 
vendors, entitlement information for users and a plu- 
rality of billing items associated with user requests for 
services provided by a vendor; 

generating a user request for services provided by a 
vendor, and comparing said user request with said 
entitlement information for said user and said contract 
information for said vendor to determine if said user 
request is an approved request; 
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transmitting said approved request to said vendor; 

generating a billing item in said database for said 
approved request; 

receiving from said vendor an invoice of charges for 
services associated with a plurality of approved 5 
requests including said approved request, and for com- 
paring said invoice with said plurality of billing items 
including said billing item; and 

allocating in accordance with said billing item, a portion 1Q 
of said invoice to said user generating said approved 
request; whereby users receiving services from said 
vendor are charged an appropriate portion of said 
invoice in accordance with services said users received 
from said vendor. 15 

6. The computer implemented method of claim 5 wherein 
said invoice of charges includes a monthly fee per user. 

7. A computer implemented method for managing a 
plurality of user requests for services provided by vendors, 
comprising: 20 

providing a database for storing contract information for 
vendors, entitlement information for users and a plu- 
rality of billing items associated with user requests for 
services provided by a vendor; 

generating a user request for services provided by a 25 
vendor; 

comparing said user request for services to entitlement 
information for said user and contract information for 
said vendor, and generating an approved request in 
response thereto; 30 

generating a billing item associated with said approved 
request and transmitting said billing item to said data- 
base; 

transmitting said approved request to said vendor; 35 
receiving from said vendor an invoice of charges for 
services associated with a plurality of approved 
requests including said approved request, and compar- 
ing said invoice with said plurality of billing items 
including said billing item; and 4Q 
allocating in accordance with said billing item, a portion 
of said invoice to said user generating said approved 
request; whereby users receiving services from said 
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vendor are charged an appropriate portion of said 
invoice in accordance with services said users received 
from said vendor. 

8. The computer implemented method of claim 7 wherein 
said invoice of charges includes a monthly fee per user. 

9. A computer implemented method for managing a 
plurality of requests from users in an organization for 
services provided by vendors, comprising: 

providing a database storing entitlement information for 
users in an organization based on at least one of the 
users' position and assigned physical location in said 
organization, contract information for vendors, and a 
plurality of billing items associated with user requests 
for services provided by a vendor; 

generating a request from a user for services provided by 
a vendor, said user being identified by at least one of 
said user's position and assigned physical location in 
said organization; 

comparing said user request with said entitlement infor- 
mation for said user and said contract information for 
said vendor to determine if said user request is an 
approved request; 

transmitting said approved request to said vendor; 

generating a billing item in said database for said 
approved request; 

receiving from said vendor an invoice of charges to said 
organization for services associated with a plurality of 
approved requests including said approved request; 

comparing said invoice with said plurality of billing items 
including said billing item to determine if said invoice 
is accurate; 

authorizing payment for said accurate invoice; 

allocating in accordance with said billing item, a portion 
of said invoice to said user generating said approved 
request based on at least one of said user's position and 
assigned physical location in said organization; 
whereby users receiving services from said vendor are 
charged an appropriate portion of said invoice in accor- 
dance with services said users received from said 
vendor. 

***** 
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ABSTRACT 



Account transaction reports from a bank card account for 
example, are assembled and sent by electronic mail or 
"email" to the email address of the account owner. An input 
screen is presented to allow the user to input the user 
preferences with regard to the substance of the report. The 
account owner is enabled to approve or disapprove each of 
the listed charges and return a user-approved marked-up 
report showing which of the listed transactions have been 
approved and/or disapproved by the user. The user-approved 
listing is returned to the account administrator and a printed 
acknowledgement of receipt of the user-approved listing is 
returned to the user by electronic mail. 
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NOTIFICATION PROCESSING SYSTEM 

RELATED APPLICATIONS 

[0001] Subject matter disclosed and not claimed herein is 
disclosed and claimed in related co-pending application, 
Attorney Docket AUS920000826US1, which is assigned to 
the assignee of the present application. 

FIELD OF THE INVENTION 

[0002] The present invention relates generally to informa- 
tion processing systems and more particularly to a method- 
ology and implementation for processing account charges. 

BACKGROUND OF THE INVENTION 

[0003] The use of account charge cards is continuing to 
expand to the extent that a charge card may be used today 
to accomplish almost any kind of transaction. Recently, 
automatic teller machine (ATM) bank account cards and 
socalled "debit" account cards are also increasing in use and 
popularity. The availability and increasing use of charge 
cards has made it much easier and faster to purchase 
anything that a buyer may wish to purchase. The expansion 
of the World Wide Web (WWW) and the Internet have also 
contributed to the rapid increase in use of transaction cards 
and also the sheer number purchasing transactions which 
may occur during any given period of time for every account 
customer or card holder. 

[0004] However, with the increasing number of transac- 
tions being made on a daily basis, it has become extremely 
difficult for the account holder to keep track of all of the 
purchases made during a billing cycle. Moreover, with more 
and more transactions being made, there is a corresponding 
increase in the number of fraudulent transactions. Generally, 
an account holder does not see a listing of charges from the 
bank account or other charge card administrator until several 
weeks after a transaction has occurred. Because of the 
relatively long time delays between the transaction and the 
reporting of the transaction to the customer, when a card is 
lost or stolen, many fraudulent charges may be made before 
the customer realizes that the card is missing and many 
fraudulent purchasing transactions occur that could have 
been avoided. Further, if there are fraudulent or incorrect 
charges that the customer wishes to dispute, the customer 
may call the bank to notify the bank of the incorrect charges. 
This process normally takes an appreciable amount of time 
and much follow-up to insure that the disputed charges have 
been recorded and, eventually, that the disputed charges are 
corrected. Further, the customer does not always have a 
record of having disputed the charges to the bank or other 
card administrator in a timely manner. 

[0005] Thus, there is a need for an improved charge 
processing system which may be implemented to help 
alleviate the foregoing shortcomings in account processing 
techniques. 

SUMMARY OF THE INVENTION 

[0006] A method and implementing computer system are 
provided in which account transaction records are assembled 
and communicated on a periodic basis. Users are enabled to 
provide user preferences including the frequency with which 
the reports are assembled and made known to the user, as 
well as which particular charges to report in terms of the type 



and/or amount of the charges. In an exemplary embodiment, 
account transaction reports from a bank card account are 
assembled and sent by electronic mail or "email" to the 
email address of the account owner. An input screen is 
presented to allow the user to input the user preferences with 
regard to the substance of the report. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0007] A better understanding of the present invention can 
be obtained when the following detailed description of a 
preferred embodiment is considered in conjunction with the 
following drawings, in which: 

[0008] FIG. 1 is a diagram of a computer system in which 
the present invention may be implemented; 

[0009] FIG. 2 is a simplified schematic diagram showing 
selected components and subsystems of the computer sys- 
tem illustrated in FIG. 1; 

[0010] FIG. 3 is exemplary illustration of a webpage 
which may be used to enable a user to input user preferences 
relative to an account report; 

[0011] FIG. 4 is an illustration showing an example of a 
transaction report presented on a user display device; 

[0012] FIG. 5 is an exemplary flow chart illustrating an 
operational sequence in one exemplary embodiment of the 
methodology disclosed herein; and 

[0013] FIG. 6 is a flow chart illustrating another exem- 
plary embodiment of the methodology disclosed herein. 

DETAILED DESCRIPTION 

[0014] With reference to FIG. 1, the various methods 
discussed herein may be implemented within a computer 
network including a computer terminal 101, which may 
comprise either a workstation or a PC for example. In 
general, an implementing computer system may include 
computers configured with a plurality of processors in a 
multi-bus system in a network of similar systems. However, 
since the workstation or computer terminal 101 implement- 
ing the present invention in an exemplary embodiment, is 
generally known in the art and composed of electronic 
components and circuits which are also generally known to 
those skilled in the art, circuit details beyond those shown 
are not specified to any greater extent than that considered 
necessary as illustrated, for the understanding and apprecia- 
tion of the underlying concepts of the present invention and 
in order not to obfuscate or distract from the teachings of the 
present invention. 

[0015] In FIG. 1, the computer system includes a proces- 
sor unit 103 which is typically arranged for housing a 
processor circuit along with other component devices and 
subsystems of the computer terminal 101. The computer 
terminal 101 also includes a monitor unit 105, a keyboard 
107 and a mouse or pointing device 109, which are all 
interconnected with the computer terminal illustrated. Also 
shown is a connector 111 which is arranged for connecting 
a modem within the computer terminal to a communication 
line such as a telephone line in the present example. The 
present invention may also be implemented in a cellular 
system. 

[0016] Several of the major components of the terminal 
101 are illustrated in FIG. 2. A processor circuit 201 is 
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connected to a system bus 203 which may be any host 
system bus. It is noted that the processing methodology 
disclosed herein will apply to many different bus and/or 
network configurations. A cache memory device 205, and a 
system memory unit 207 are also connected to the bus 203. 
A modem 209 is arranged for connection 210 to a commu- 
nication line, such as a telephone line, through a connector 
111 (FIG. 1). The modem 209, in the present example, 
selectively enables the computer terminal 101 to establish a 
communication link and initiate communication with a 
network server. The network may comprise a direct connec- 
tion through an Internet Service Provider (ISP) to a server on 
the World Wide Web (WWW) or the network connection 
may be to a local area network server for further connection 
to the WWW. 

[0017] The system bus 203 is also connected through an 
input interface circuit 211 to a keyboard 213 and a mouse or 
pointing device 215. The bus 203 may also be coupled 
through a hard -wired network interface subsystem 217. A 
diskette or CD drive unit 219 is also shown as being coupled 
to the bus 203. A video subsystem 220 7 which may include 
a graphics subsystem, is connected to a display device 221. 
A storage device 218, which may comprise a hard drive unit, 
is also coupled to the bus 203. The diskette/CD drive unit 
provides a means by which individual programs may be 
loaded on to the hard drive, or accessed directly, for selective 
execution by the computer terminal 101. As is well known, 
program media containing application programs represented 
by magnetic or other indicia on the medium, may be read 
from the drive unit, and the computer system is selectively 
operable to read such indicia and create program signals. 
Such program signals are selectively effective to cause the 
computer system to present displays on the screen of a 
display device and respond to user inputs in accordance with 
the functional flow of the application program on the 
medium or as loaded into memory. 

[0018] In running an Internet access program or browser 
program on the computer terminal 101, the access program 
is typically stored in the storage device 218 and either 
selectively or automatically, partially or totally, loaded into 
the system memory 207 when the system is initially pow- 
ered-on, or at a later time if so desired by a user. The browser 
is selectively operable to access and execute a site selection 
program, as herein described. As a program is running, 
either a portion of the program or the entire program may be 
loaded into the system memory 207 and/or the system cache 
memory 205. 

[0019] Depending on specific program design, the system 
may store any information accessed from a database in the 
storage unit 218, the cache memory 205, the system memory 
207 or directly from a diskette or CD loaded into the 
medium drive unit 219. Assuming a user has started-up the 
system, and is actively running a browser program for 
example, from memory, a series of screens will be displayed 
to the user on the display device 221. Each screen typically 
has one or more selections for the user to make in navigating 
through the program. In general, a user will make selections 
from a home page display screen using the keyboard 213 or 
the mouse or pointer device 215. The selections made by the 
user will determine "where" the user "goes", i.e. to what 
"site" or "webpage", and also, in some cases, the commu- 
nications link or the path taken to get to the WWW site 
selected. 



[0020] FIG. 3 illustrates a browser program screen display 
301. The browser screen generally includes a first row 303 
of function buttons. The function buttons may be selected by 
a user with a pointer device using a "point-and-click" 
methodology which is well known. A user may select a 
"File" button 308 or a "Bookmarks" selection 304. Another 
row 305 may be displayed to help a user quickly move 
through documents, sites, or pages in a browser application. 
A user may terminate any session with a web page by 
actuating a terminate button 306. An address or "location" 
section 307 enables a user to key-in, and also displays the 
name of, a WWW address of a site to be, or being, visited. 
In general, any of the illustrated items may be selected 
through a "point and click" methodology associated with the 
mouse device 215, and a cursor or pointer 320 visible on the 
display screen. For example, a download of data from a 
remote site may be immediately terminated during the 
transmission by pointing to the "Stop" button and clicking 
on a designated mouse button. Similarly, the "Back" and 
"Forward" buttons may be used to return to the last screen 
display or go forward to the next screen display, respec- 
tively. 

[0021] In the exemplary screen illustrated in FIG. 3, the 
user has accessed the location of a web site ("MYAC- 
COUNT.com") of an account administrator such as a bank 
account or charge card account which is owned by the user. 
As shown, a screen is presented to the user which enables the 
user to input user preferences 312 with regard to an account 
report. In the illustrated example, one section 315 of the user 
preference input screen enable a user to specify the fre- 
quency of the reports. If, using a mouse or other pointer 
device, the user points to and clicks a screen pointer 313 on 
the block next to the "DAILY" selection as shown, the user 
has indicated that a daily report of charges made to his 
account is desired. Similarly, a user may select other fre- 
quencies such as weekly, biweekly or monthly reports in the 
example. 

[0022] In another section 317, the user may select other 
user preferences with regard to a periodic report of charges 
made against the user account with the bank issuing a charge 
card for example, [n the example, the user may select to have 
all transactions reported 319, or only to have transactions 
321 over a designated amount reported. The reports may be 
made merely by posting the information on an account web 
page to be accessed by the user. In a preferred embodiment, 
the user is enabled to designate 323 that the reports are to be 
sent to the user via email, and the user is able to input the 
particular email address 324 to which the user wishes to 
have the reports submitted. Other preferences 325 may also 
be specified by the user. When the user has provided the 
user's report preferences, the user is able to point and click 
on the hypertext "SEND PREFERENCES"327 to send the 
preferences to the account server, or the user may terminate 
the session without input by actuating the terminate block 
306. When the user preferences are sent to the account 
server, they are stored by the server and are referenced and 
used in providing periodic account transaction reports to the 
user by the designated means. In this way, a user is able to 
view transactions in a prompt and efficient manner to insure 
that the posted transactions are accurate. 

[0023] In the exemplary report 401 illustrated in FIG. 4, 
a daily report has been sent to a user via the designated 
user's email address. The report 401 includes a series of 



01/09/2003, EAST Version: 1.03.0002 



US 2002/0073050 Al 



3 



Jun. 13, 2002 



listings which show various transactions 405 that have 
posted to the user's charge account during the indicated date 
403. The report also shows the amount of the charge 407. 
The display also provides means for the user to either 
approve 409 or disapprove 411 of each of the charges in the 
listing. A user may, for example, use the pointer 413 to 
approve all of the listed charges except one, which is not 
approved by the user. The report in the example is sent to the 
user on the day following the posting of the charges so that 
both the user and the bank are able to identify potentially 
incorrect charges at a very early point in time and signifi- 
cantly reduce the potential for fraudulent or otherwise 
invalid charges. This early detection is enabled through the 
use of an automated email report and response as herein 
described. 

[0024] In the example shown in FIG. 4, by actuating the 
appropriate hypertext, the user is able to print the report 415 
to a printer to provide a written record of the charges. 
Similarly, the user may print the marked-up report (i.e. the 
report showing the approved and disapproved blocks), and 
return the marked-up report 417 to the bank server, and exit 
the program. The user may also merely exit the report 419 
without mark-up. The report may also include a quick and 
easy way to notify the bank of a lost or stolen credit, debit 
or ATM card by clicking on the designated hypertext 422. 
Other user preference options may also be included for 
selection by the user. 

[0025] As shown in the flow chart of FIG. 5, a bank server 
starts the methodology 501 by making a determination as to 
whether or not it is time 503 for a periodic report to a user 
or account owner. That determination is made with reference 
to the user input which specified the frequency of reports as 
discussed in connection with FIG. 3. The determination can 
be made, for example, by running the appropriate code at the 
beginning of or at the end of every day. Next, if it is time for 
a periodic transaction report to the user, the transactions are 
retrieved 505 and the report is assembled 507 in accordance 
with the input provided by the user in the Report Specifi- 
cation 317. Next, the report is delivered 509 and the process 
returns to await the next reporting time 503. The report may 
be delivered in several ways. The report may be delivered by 
posting the report to a web site which may be accessed by 
the user, or by sending an email to the user which contains 
the report within the email. 

[0026] FIG. 6 illustrates an email report delivery in more 
detail. As shown, the processing begins 601 with the deter- 
mination that the time has come for the bank server, for 
example, to deliver a report 603 to a user or customer as 
specified in a user preference file. Next, the transactions 
which have occurred during the reporting period are 
retrieved 605 and assembled in email format 607. The report 
is then emailed to the user 609 using the email address 
provided by the user 324. Next, if no reply is returned to the 
bank from the user 611 the process returns to await the next 
time a report is due 603. If, however, the user checks off the 
blocks as shown in FIG. 4 and returns the marked-up report 
to the bank 611, the reply is processed by the bank or other 
institution administering the user's account, and an email 
acknowledgement is returned to the user 615. The process 
then returns to await the next reporting time 603. The email 
acknowledgement 615 from the bank acknowledges the 
user's dispute of the indicated charge (FIG. 4) and gives the 
user a record of the user's timely disapproval of the charges 



so marked. The bank is thereby quickly able to process the 
dispute and resolve the matter in a timely fashion. It is noted 
that security provisions may also be added and included in 
the processing to insure confidentiality of the communica- 
tions between the bank and the user. 

[0027] The method and apparatus of the present invention 
has been described in connection with a preferred embodi- 
ment as disclosed herein. The disclosed methodology may 
be implemented in a wide range of sequences, menus and 
screen designs to accomplish the desired results as herein 
illustrated. Although an embodiment of the present inven- 
tion has been shown and described in detail herein, along 
with certain variants thereof, many other varied embodi- 
ments that incorporate the teachings of the invention may be 
easily constructed by those skilled in the art, and even 
included or integrated into a processor or CPU or other 
larger system integrated circuit or chip. The disclosed meth- 
odology may also be implemented solely or partially in 
program code stored on a CD, disk or diskette (portable or 
fixed), or other memory device, from which it may be loaded 
into memory and executed to achieve the beneficial results 
as described herein. Accordingly, the present invention is not 
intended to be limited to the specific form set forth herein, 
but on the contrary, it is intended to cover such alternatives, 
modifications, and equivalents, as can be reasonably 
included within the spirit and scope of the invention. 

What is claimed is: 

1. A method for processing a charge account report for 
periodic display to a user, said method comprising: 

selectively presenting a user preference screen on a user 
display device; 

enabling said user to define a customized report display 
by selecting user preferences with regard to variable 
characteristics of said charge account report; and 

periodically assembling charge account transaction data 
to include in said customized report display. 

2. The method as set forth in claim 1 and further including 
making said customized report display available to said user. 

3. The method as set forth in claim 2 wherein said 
customized report display is made available for access from 
an account server site through a network connection. 

4. The method as set forth in claim 3 wherein said 
customized report display is made available by sending a 
report-related email to said user. 

5. The method as set forth in claim 1 wherein one of said 
user preferences is a frequency with which said customized 
report is made available. 

6. The method as set forth in claim 1 wherein one of said 
user preferences represents a minimum transaction amount 
to be included in said customized report display. 

7. The method as set forth in claim 1 wherein one of said 
user preferences represents a selection to include all trans- 
actions which have occurred since a prior report. 

8. The method as set forth in claim 1 and further including 
sending said customized report display to said user display 
device by email. 

9. The method as set forth in claim 8 and further including 
sending said customized report display to said user display 
device as an attachment to said email. 

10. The method as set forth in claim 8 and further 
including sending said customized report display to said user 
display device as an integral portion of said email. 
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11. The method as set forth in claim 8 wherein said 
customized report display is sent to said user automatically 
by an account server through a network connection. 

12. The method as set forth in claim 8 wherein said 
customized report display is encrypted prior to sending said 
email, said customized report display being de-encrypted by 
said user after receiving said email. 

13. A storage medium including machine readable coded 
indicia, said storage medium being selectively coupled to a 
reading device, said reading device being selectively 
coupled to processing circuitry within a computer system, 
said reading device being selectively operable to read said 
machine readable coded indicia and provide program signals 
representative thereof, said program signals being effective 
to enable a processing of a charge account report for periodic 
display of said report to a user, said program signals being 
selectively operable to accomplish the steps of: 

selectively presenting a user preference screen on a user 
display device; 

enabling said user to define a customized report display 
by selecting user preferences with regard to variable 
characteristics of said charge account report; and 

periodically assembling charge account transaction data 
to include in said customized report display. 

14. The medium as set forth in claim 13 wherein said 
program signals are further effective for making said cus- 
tomized report display available to said user. 

15. The medium as set forth in claim 14 wherein said 
customized report display is made available for access from 
an account server site through a network connection. 

16. The medium as set forth in claim 15 wherein said 
customized report display is made available by sending a 
report-related email to said user. 

17. The medium as set forth in claim 13 wherein one of 
said user preferences is a frequency with which said cus- 
tomized report is made available. 

18. The medium as set forth in claim 13 wherein one of 
said user preferences represents a minimum transaction 
amount to be included in said customized report display. 

19. The medium as set forth in claim 13 wherein one of 
said user preferences represents a selection to include all 
transactions which have occurred since a prior report. 



20. The medium as set forth in claim 13 wherein said 
program signals are further effective for: 

sending said customized report display to said user dis- 
play device by email. 

21. The medium as set forth in claim 20 wherein said 
program signals are further effective for sending said cus- 
tomized report display to said user display device as an 
attachment to said email. 

22. The medium as set forth in claim 20 wherein said 
program signals are further effective for sending said cus- 
tomized report display to said user display device as an 
integral portion of said email. 

23. The medium as set forth in claim 20 wherein said 
customized report display is sent to said user automatically 
by an account server through a network connection, 

24. The medium as set forth in claim 20 wherein said 
customized report display is encrypted prior to sending said 
email, said customized report display being de-encrypted by 
said user after receiving said email. 

25. A processing system comprising: 

a user terminal, said user terminal further including a 
system bus, a CPU device connected to said system 
bus, a memory device connected to said system bus, an 
input device connected to said system bus, said input 
device being arranged to enable user input to said user 
terminal, and a user display device connected to said 
system bus; and 

a server terminal, said server terminal being selectively 
operable for being connected to said user terminal, said 
processing system being selectively operable for 
enabling a processing of a charge account report for 
periodic display of said report on said user display 
device, said processing comprising selectively present- 
ing a user preference screen on said user display device 
for enabling said user to define a customized report 
display by selecting user preferences with regard to 
variable characteristics of said charge account report, 
said processing further including periodically assem- 
bling charge account transaction data to include in said 
customized report display. 

***** 
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